The buyers and the original hackers would then use the data to try and gain access to user accounts across the internet. Not just on the sites that were breached but also on other domains, Working under the persuasive and well-known assumption that users mostly use the same credentials on many sites.

These breached usernames and password haul contained millions and millions of combinations. No self-respecting bandit would be trying to compromise sites manually, entering each username and password to see if they work. They would create some automated way of doing this using the tools found in any decent hackers toolkit or half-decent programmer. So this computerised practice of injecting username and password pairs to gain access to a user's accounts became known as credential stuffing.

Eventually, those treasure troves, including emails, passwords, and in some cases, more sensitive information, found their way into many people's hands.

Listen to Rework Podcast on Credential Stuffing

There is a great podcast that describes how the Basecamp security team handled the attack on their services Listen here

Remember, they have decided they need to have a deeper interaction with you, they want more of your services and or products, they have gone the extra mile and you've slapped them in the face and made them feel rejected or dejected if for some reason, they cannot sign up for an account on your digital platform.

Case One: No money from me

I received a bill from my water supplier company. It wasn't the first bill I had from them, and I went to log into my account on their website, but found my login credentials were not recognised. Undaunted, I proceeded to sign up for an account, prompted even more so because they were promoting their new account service via the bill with the tag line 'you asked and we listened'

I entered the url of the page, and was presented with a simple form that asked for three things

• My Account number
• My postcode
• My email address

Nice, I entered the details and pressed the 'Register' button. The system told me my email address was already in use. Hmmm, ok so my next course of action was to go to the forgotten password link. I entered my email address and was told an email was winging it's way to my inbox with instructions of how to reset my password.

Success! or so I thought.

The next 15 minutes was spent in a frustrating cycle of password resets, lockouts, entering verification codes and bollocks!

In the end, I gave up. I also didn't pay my bill. Whilst I will pay it using some other means, because I have to, the company has failed to secure renumeration from a customer who was willing to give it to them, due to a failure in their account creation/login system.

Imagine if I didn't have to use this company at all, they would have lost my money forever.

Case Two: What the hell?

This second case is equally as annoying as the first. Whilst I have an account with this second company, again a utility company, they have some strange phenomena that only logs my account in if I use a link that was previously sent in an earlier email. If I hit the login link from their website it doesn't recognise my credentials.

This has happened on numerous occasions and frankly I've had enough and will be switching from them very shortly.

Prevention is better than a cure

Without a through Quality Assurance (QA) process, you cannot be sure that your account creation/login system works for the customer 100% of the time, or at least ir 99.9993% of the time.

An account management system must have the following processes

• Sign up (new account creation)
• Verification
• Login
• Forgotten/Reset password
• Forgotten username
• Logout

Each of these processes should be thoroughly tested to ensure the user journey can be completed with minimal fuss and disruption.

We would suggest the following test scenarios in each journey

Sign up

• Can the user access the sign up page easily from any page on your site
• Can the account be created with minimal information
• Does your sign up verify the user's email or phone
• Can the user create their own username
• Does the verfication process work effortlessly
• Do you show validation messages for fields that required strict formats or criteria (e.g. correct email formatting or password length/composition)

Verification

• Does verification via phone (usually sms) work
• Does veritication via email work
• Is verification form accessible via a link from your website
• Once verification complete is the user automatically logged in or is user re-directed to the login page

Login

• Can the user access the login page easily from any page on your site
• Does the system allow passwords to be copied and pasted into the password field (primary importance for users that use password generator systems)
• Does the user receive clear messages and instructions if login has failed
• If the account is not found, is the user directed to create an account

There are other checks that you can do but you should have the bare bones above to help you design a system that works for you and for your customers.

Cascading Style Sheets (CSS) were developed so that you can describe how to render your web pages separately from the HTML or XML markup.

If we don't separate the layers, we find that maintenance or improvements can be fraught with issues.

Separation is essential in modern web application development. This is due mainly to our constant need to make changes to our applications to allow for new and improved user experiences or business needs.

Sometimes our new stuff breaks the old stuff; things don't look the same or appear in the wrong places. There are even times when we break working functionality. This can be detrimental to the way our users experience our applications or website. It can also cost us money.

If you are someone that has been involved in launch day changes that have had to be rolled back because the customer services switchboard has lit up like an 80's rave, then you know what I mean. As with all the books in this series, I've attempted to simplify the descriptions and explanations. There are very few code examples in this book as it is not aimed a people who write the code. The information in this book is abstracted to a level that I think is appropriate for managers, team leaders, product managers and business owners. If you work in any of these roles, this book was written explicitly for you.

With this series, you will no longer be in the dark about what your developers are saying. You'll understand some of the terminologies and feel comfortable that the tech doublespeak is not going conclusively over your head.

You will have enough knowledge to feel comfortable and not bamboozled with tech speak. With CSS A to Z, you will become Tech Savvy.

Enjoy!