Introduction\n\nOne of the most beautiful aspects of life is that everyday is a school day 😀. Certain lessons you seek out yourself, with a drive and thirst for knowledge and a passion for self improvement. Others however, well, let's just say find you! Fresh from the school of hard knocks, life has a (sadistic) habit of just happening and it is really important that we can roll with the punches and learn from our experiences. It must have been quite the experience for the Company in Question (CiQ) when, upon answering a question on Twitter regarding their password reset practices, they received a tsunami of criticism from information security community due to the methods they admitted to using. Their admitted methods of setting, storing and resetting passwords were certainly out of the ordinary, and they were subsequently informed of this by a LOT of people!!! I've included the initial question from the user and the subsequent answers by the CiQ below (just in case they are taken down), but I recommend that you definitely take the time to visit the thread in its entirety and read the feedback.\n\nUser asking the Company In Question (CiQ) a password-related security question.\n\nThe Company in Question's justification thread (1/7)\n\nThe Company in Question's justification thread (2/7)\n\nThe Company in Question's justification thread (3/7)\n\nThe Company in Question's justification thread (4/7)\n\nThe Company in Question's justification thread (5/7)\n\nThe Company in Question's justification thread (6/7)\n\nThe Company in Question's justification thread (7/7) Fin\n\nThe CiQ Twitter Thread\n\nIt is never pleasant to be dog-piled on the internet, even when the criticism is valid (like in this case) and people are offering suggestions of valid improvements. Unfortunately, it all just appears as a massive wall of text that tells you how bad you are, documented for the world to see in an embarrassing fashion. This post isn't to actually criticize anyone or throw any party under a bus, rather I aim to use this as a learning opportunity. Clearly there were some security misunderstandings during the development of their site that has lead to security best-practices and standards to not be followed, and here I will go through some of the justifications made by the CiQ and make suggestions on how their systems could be improved. Security isn't easy, and taking a secure-by-design approach can be costly and very time consuming. However, if we really want to take the privacy and security of our users data seriously, we need to at the very least understand the basics especially if you are a company like the CiQ.\n\nAn Unfortunate Answer\n\nNot being able to sugar coat this, the response provided by the CiQ to the user doesn't confirm to anything that the current updated standards and best practices recommend when managing password management for your service. Their approach taken will work if their systems were unhackable (no system is unhackable), as it wouldn't matter how passwords are generated and stored. However in the real world, we need to design our infrastructure with defence-in-depth so that supplementary protective measures are used if certain ones fail, along with separation-of-concern so that if we are eventually compromised, what an attacker can do and/or steal is limited. Their (admitted) approach in their response however doesn't demonstrate any of this. With all the issues surrounding passwords highlighted in the NCSC Password Policy Infographic that I've attached, we need to be doing a little more than what is stated by the CiQ.\n\nI'll firstly start with how passwords are created and stored. The password, or user secret is supposed to be something that ONLY THE USER MUST KNOW AND CAN KNOW. They use it, along with their identity to authenticate with a system as themselves. Not allowing a user to ever pick their secret and rather ONLY generating it server-side and sending it to the user is an "interesting" way to deal with this, but actually COULD work as long as ONLY THE USER ever sees the generated secret in it's plain form. To be fair to the CiQ, I can see that they are trying to combat the problem where users reuse the same password across different services which leaves many accounts vulnerable should one service be compromised. Unfortunately, their approach breaks down as the password is stored in plaintext, meaning that potentially any administrator of the application database can freely read every password. This allows any rogue employee to freely impersonate any user and also bypass any back-end monitoring systems, or even share them outside of the CiQ. This doesn't even include hackers, who could do the same if they infiltrated the system and dumped the database.\n\nPassword reuse is actually a well-known activity that MANY users partake in, so it makes sense that the CiQ wants to tackle it on their platform. By them not allowing users to set their own passwords, and instead forcing upon them a randomly-generated password, their users will be FAR less likely to reuse. They are responding to an issue OWASP explicitly mention in their password-storage guidelines:\n\nAs the majority of users will re-use passwords between different applications, it is important to store passwords in a way that that prevents them from being obtained by an attacker, even if the application or database is compromised.\n\nDeveloper getting annoyed at having to deal with users reusing passwords on their platform!\n\nOf course this is until they start putting the randomly generated password into other services 🤣! I actually don't have a problem AT ALL with passwords that are randomly generated by the provider, as long as users are given the choice and control they need to administer their own secrets. Also, there are other means of protecting passwords, which include ensuring suitable complexity (NOT by using stupid password rules, which are stupid), blocking usage against breached password lists and by advocating the use of password managers which themselves generate and store secure, random passwords. All of these methods are also recommended by standards 😀.\n\nSimon: Stupid Password Rules Are Stupid\n\nZXCVBN: Low Budget Password Strength Estimator\n\nPwned Passwords API: 555M Known Breached Passwords\n\nSecLists: Known Breached Passwords\n\nNCSC: Top Tips for Staying Secure Online Password Managers How they Help You Secure Passwords\n\nIf the passwords were stored properly (more on this shortly), then even if someone malicious stole the passwords, it would take a HECK of a lot of computing power and MANY years to convert them into a usable form, especially as the passwords they generate server side are random (and hopefully long). This would obviously mean they wouldn't be able to email out passwords, which they really SHOULDN'T be doing anyway (I'll come to this). If you want to see timescales, try generating a long random password using the generator below and checking against the two password validation sites.\n\nStrong Random Password Generator\n\nDropbox's Password Strength Checker\n\nHow Secure is My Password?\n\nThe randomly generated password K(X)n'j&A'a9#f~n(e2c5^uafn9JP6c6 could take ~ 2 quattuordecillion years to crack 😱\n\nI now want to address the statements around password "encryption" that they keep mentioning and trying to use justify plaintext storage. Remember, a password (or secret) is something that ONLY THE USER MUST KNOW. Passwords thus should be stored in a manner that facilitates this dynamic, and unfortunately neither plaintext nor encryption meets this criteria. Both schemes enable the service provider (the CiQ) to potentially retrieve the secret whether it is just by reading (plaintext) or via decrypting (encryption). Instead, the OVERWHELMING advice via standards and best-practice is to put the password through a one-way, salted (so identical passwords yield different results), slow hashing algorithm prior to storage. These include Bcrypt, PBKDF2 and Argon2id, and their role is to turn plaintext passwords into absolute random garbage so that no one in their right mind can determine what the original input was. Also, because they are (intentionally) slow and one-way, it's IMPOSSIBLE to obtain the original password from the nonsense (unlike encryption). Authentication is achieved by hashing any subsequent password submissions and comparing the output with the one stored. The CiQ shouldn't be storing passwords in plaintext as they are not protecting the data at rest, and they definitely shouldn't be talking about encryption when referring to passwords. I've included some relevant guidance below.\n\nNIST Special Publication 800-63B Digital Identity Guidelines Authentication and Lifecycle Management: 220.127.116.11 Memorized Secret Verifiers\n\nNCSC Password Administration for System Owners: Protect Passwords at Rest\n\nOWASP Password Storage Cheat Sheet\n\nWhen the CiQ says "If we encrypted the password that would mean we do have your password, it's just encrypted and there is a chance even 0.01% for it to be decrypted", we need to compare this to storing it in plaintext, where the chance of password decryption is 100%. They are arguing that this is safe as they generate your password, which is a bit of a stretch as it is still YOUR secret that they are obliged to manage. Who creates the password is totally irrelevant, it should be stored securely in accordance with standards and best practice. Plaintext storage can be very dangerous for the reasons already outlined.\n\nNow we come to my "favourite" 😏 part, where they state they don't store an encrypted version of the generated password so that they can send it within a reminder email if you forget your password. It is my "favourite" 😉 as is shows a FUNDAMENTAL lack of understanding of how the forgotten password process is supposed to work. You are NOT supposed to email people their password when they forget it as email is NOT a secure medium to manage passwords. It can be monitored by third parties such as your email provider and even your organisation, and in many cases isn't even encrypted when transported. Also, as many services use the email address as the username (identity), when emailed you have the username and password sitting there out in the open! There is a page dedicated to this very serious misunderstanding called Plain Text Offenders and I've included a link below.\n\nPlain Text Offenders\n\nInstead of emailing the user their password when forgotten (which happens a lot), the CiQ should force the user (and only that user) to reset their existing password. The provider should verify the user by using a time-limited, out-of-band method that ONLY the user controls (e.g. via email, 2nd factor) to make it more difficult for an attacker to perform as only the user should have access. This could be a one-time link and/or passcode sent to the user which they use ONE OF the steps in the password reset process. The OWASP have an excellent cheat sheet on this very process which shows all the steps very clearly 😀\n\nOWASP Forgot Password Cheatsheet\n\nNow we move to the unnecessary part of the thread, where the CiQ moves to dismiss concerns based on their lack of perceived value of the data stored (a pet peeve of mine). Firstly, they state that should an attacker compromise the system, they would have far more valuable things to look up than the password generated. True, however a totally irrelevant thing to say. The point of defence-in-depth is EXACTLY this, where you put sufficient roadblocks in place so that the attacker DOESN'T have access to everything. You don't just dismiss the importance of certain data because people criticized the practices that you use. Your job is to make your each component of your overall system difficult to compromise.\n\nThey then go on to detail what they actually store in their database which includes email (Personally Identifiable Information [PII] under GDPR), a nickname (might be PII depending on what is used) and the password they generate (required to be protected). They further downplay the significance of this information by mentioning that they don't store credit card information. Again, the fact that you don't store financial information totally irrelevant. You DO store email which is classified as PII, and you do store a user secret which you are REQUIRED to sufficiently protect when at rest. Heck there is a line in the NIST standard that covers this VERY succinctly:\n\nVerifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function.\n\nThe NCSC also take a very strong view on the storage of passwords, irrespective of the level of importance you deem the information to have:\n\nMake sure the systems you deploy do not store passwords as plain text, even if the information on the protected system is relatively unimportant.\n\nThis shows that the standard bearers and authors of best practice don't care about how important you think your data is. Thus the CiQ's use of the words "the only information stored" has been rendered totally useless. If you need to protect your data behind authentication, you MUST protect (i.e. hash) the secrets used to authenticate against your system. The NCSC even goes as far as to state to NOT use plaintext, so the advice is pretty clear. Instead, providers should use one of the aforementioned hashing algorithms when storing passwords.\n\nA Comment on the Situation\n\nThe CiQ didn't cover themselves in glory by putting out this information they clearly thought was correct. Security is tough, but the descriptions used suggest that they may not have read any of the freely available guidance and standards available when developing their password management routines. If they had, they unfortunately didn't convey this in the official statements they released. Hopefully they will consider the constructive feedback they received from the information security professionals and use it to improve the system that they already have in place so that it follows the guidance and adheres to the standards. If not, then they should be looking out for potential breaches of data just in case this perceived lack of understanding has carried over into other components of their system which has been developed.\n\nI'm hopeful that people and organisations can learn and change. However, they need to have the desire to better themselves. Companies which don't want to learn would ignore this feedback and double down on their existing posture much to the detriment of their users. Let's hope that this particular organisation is willing to learn from their mistakes and come back stronger 😀.\n\nSecurity is Hard\n\nSoftware development can be long and laborious, and getting security correct is no easy task. Thankfully there are many freely available standards and guidelines available to make the process smoother and mean that you don't always have to innovate on tried and tested processes. It is totally fine to come up with your own way of doing things, but it is important that you open up your implementation to scrutiny as this is the only way that we can all learn and advance. Also, an important rule of thumb is to TRY and LISTEN to the people whose job it is to circumvent, break, breech, harden and standardize security for systems as they are probably the best-placed to to give you advice! If they are telling you that your 'password storage' and 'forgotten password' processes are bad from a security point of view (bearing in mind it is their profession to know this), then you probably have some work to do! Finally, it doesn't matter how unimportant you deem the data you store to be, if you are managing it on your systems, then you have to take it seriously.\n\nTake care and all the best. Si.