Is it secure to store passwords with 2 way encryption?

Question

I'm a parent who has a parent account with my local school district so that I can log in to their website to view my child's grades etc.

I clicked the "forgot password' button, and my password was emailed to me in plain text. This concerned me, so I emailed the principal, including some links from the bottom of this page. This is the reply I received from the organization's IT department:

Parent passwords are not stored in plain text. They are encrypted. Not a 1 way encryption but a 2 way encryption. This is how the system is able to present it back via an email through Ariande's CoolSpool utility.

For support reasons, the parent password is visible to certain staff until the parent has successfully signed in 3 times. After that, no staff can see that password. However, it is stored in such a way that the system itself can send it back to the verified email. In the future after a parent's 3 successful sign ins, if they forget their password, their verified email account will be sent a link to reset their password, this change is in the works.

Does this explanation justify the plain text password being sent by email, and are my passwords secure with them?

If not, what references or resources could I reply to them with?

Answer 1

No, this is not a good practice. There are two distinct problems.

• encrypting the password instead of hashing it is a bad idea and is borderline storing plain text passwords. The whole idea of slow hash functions is to thwart the exfiltration of the user database. Typically, an attacker that already has access to the database can be expected to also have access to the encryption key if the web application has access to it.

  Thus, this is borderline plaintext; I almost voted to close this as a duplicate of this question, because this is almost the same and the linked answer applies almost directly, especially the bit about plaintext offenders; there is another answer about plaintext offenders as well.

• sending the plain text password via plain text email is a bad idea. They could argue that there is no difference when no password reuse happens, but I doubt they would even know what that is and why it’s considered bad practice. Also, password reuse is so common that that wouldn’t be a good answer.

Additionally, as they seem to be working on the second part (even though password reset links in plain text emails are in the same ballpark, i.e. a threat that can read the password from the plain text mail can also read the link, maybe before you can), you could explain them the problem about not hashing from my answer, also feel free to link this answer directly.

Maybe even explain that encryption is one way, but can always be reversed by the inverse function of the crypto system in question, aptly named decryption. Using terms like "one way encryption" and "two way encryption" rather than "hashing" and "encryption" shows a lack of understanding.

The real problem is: them implementing a password reset does not mean they will hash (correctly) in the future; there is not much you can do about this except using a password manager and create a long, strong passphrase that is unique for this site and hope for the best.

This is especially true since they seem to want to keep the part of their system that tells staff your password (for absolutely no good reason). The implication being they keep not hashing properly - them saying staff can only see the password in that three login timeframe is not true; if the web app can access the key, so can the administrative staff. Maybe no longer the customer support staff but they shouldn’t be able to see it in the first place. That is horrifically bad design.

Depending on your location, schools as being part of the public sector have obligations to have a CISO you can contact directly, expressing your concerns. And as usual in the public sector, there ought to be an organization that is supervising the school; they should have a CISO at least, who might be quite interested in this proceeding.

Answer 2

Everyone is focusing on the encryption vs. hashing but, while that is bad in itself, I find the following more egregious:

For support reasons, the parent password is visible to certain staff until the parent has successfully signed in 3 times.

You should interpret this as "the IT staff knows my password". They openly admitted that certain members of their staff can know your password. This is beyond bad. I'm assuming this counter is reset after you change your password, so using a dummy password three times and then changing it to a 'real' password won't do anything. Don't put anything on that platform that you don't want publicly known, and if you used the same password on other sites, change them.

Answer 3

No, as you correctly surmised, this behavior is clearly not secure.

What you can and should do is not trust their system. Don't use a password on the school system that is anything like your banking or other passwords. Don't put in any more information than is absolutely required to get your child through school. If your child brings home a note that says to "log in and update your info", don't put in anything you are uncomfortable revealing.

At least their "in the future" scenario sounds like they are implementing the behavior they need in order to support securely hashed passwords; whether or not they will actually securely hash the passwords (after three logins) instead of encrypting them will be a different question. And you won't be able to answer that question by observation. If you are still concerned, you could contact the software vendor and ask them how it works.

Answer 4

1. You shouldn't assume your password is ever secure. There's a reason why password managers are the recommended way to go

   The reality is that in your attempts to handle all those passwords yourself, you will commit the cardinal sin of reusing some. That is actually far more risky than using a password manager. If a single site that uses this password falls, every account that uses it is compromised. You'll need to remember all the sites where you reused that password and then change them all.

2. The recommended way to do a reset is to generate a unique key for a user to do their own reset on a TLS secured website. Email, even with TLS enabled, is still inherently insecure

   Although TLS and SSL undoubtedly form a vital foundation for any company's approach to data security, there is still some evidence to suggest that it is a system that carries with it a number of potential vulnerabilities.

   The main point of weakness arises from the lack of understanding from companies about how to encrypt emails, with many believing the transport channel, and thus the email, to be fully secured with the use of TLS.

3. Hashing is fundamentally different from encryption. This was well explored on Stack Overflow

   [Encryption functions] provide a 1:1 mapping between an arbitrary length input and output. And they are always reversible.

   As SmokeDispenser noted, if they can get your database, they can get the encryption key. How does this differ from hashing? Hashes are always one-way. Data goes in and never comes out. In other words, there's no keys to steal.

   Use a hash function when you're checking validity of input data. That's what they are designed for. If you have 2 pieces of input, and want to check to see if they are the same, run both through a hash function. The probability of a collision is astronomically low for small input sizes (assuming a good hash function). That's why it's recommended for passwords.

   In other words, you store your password on my site. I hash it with a random string (called a salt) over and over with something slow (like bcrypt). To validate you, you input your password again and I wash it through the same hash. With the same algorithm (plus however many times I ran over it, called cost), salt, and password, I should get the same hash I have stored. Thus, I have no need to store a reversible encrypted, or an unencrypted password.

Answer 5

By definition, if a password is stored by someone other than you, then it is not stored securely. There is never any need to store your password.

If IT personnel ever have a legitimate reason to access your account without you providing the password, they don't need your password stored somewhere. They can do a password reset, access your account, replace your password with the original. All without ever knowing your password.

If they can send your password to you, then they can send it to someone pretending to be you. So it's not secure.

PS. They absolutely don't need to store the password for authentication. They can store a salted hash, from which recovering the password is impossible. That's the standard practice. How can they send it to someone pretending to be you? That's called social engineering. Someone calls, convinces them that it's you and that your email address has changed, and they send the password to the wrong person.