Is it secure to store passwords with 2 way encryption?
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?
*Can you count? Count on yourself!* Don't reuse passwords, use password manager.
Without reading beyond the title of your question for the details I could answer "No" and be 99.999 % certain that I was correct. Companies and organizations whose main focus is internet communications get this wrong. An underfunded school district whose purpose in existing is entirely different and merely uses electronic communication as a readily available convenience can hardly be expected to understand the subtleties of security. The real question is not "are they" but "why and how aren't they".
The fact that the IT guy made 2 typos in a single software title's name is as much telling as the fact that you did get your password sent by mail...
Krikey! This Cool Spools thing is IBM! Maybe schools are short of money and expertise, but that's why they use vendors. No excuse for this. None.
"the parent password is visible to certain staff" -- using a password manager and being careful what you put on the platform doesn't even help with this. Your password is known by other parties, therefore you can be impersonated
The fact that staff can see passwords under any circumstances is really worrisome given how many people use a single password for everything. Are users notified of this when they sign up?
Those comments from the IT department not only confirm your fears, they also reveal serious additional flaws: they let staff see your password - I mean WHY?!! There is no justifiable reason for that either. I would not be surprised if it was in violation of some regulation they were supposed to follow.
It's off-topic for this site, but assuming U.S. Federal law applies, the fact that "the parent password is visible to certain staff" means that this system is incapable of detecting illegal FERPA access to protected education records and personally identifiable information by said staff.
They clearly put a lot of thought into this and came up with the wrong answers. I would be more understanding if they had simply not thought a lot about this (educating children not internet security should be their focus). Since they thought so much about it and still FUBARed, I have to assume they are just as bad at pedagogy. Forget about the password. You are homeschooling now.
@Blorgbeard: Using a password manager definitely helps when the password is visible to site staff. Because you are using a password manager, what they have is a site password derived from the master and keychain together, not your master password. So it will do them no good in accessing other accounts. Sure, it's possible to have hundreds or thousands of unique per-site passwords without a password manager, but completely impractical. So the real-world effect of staff access to passwords and not using a password manager is that they learn a password that is reused on some group of sites.
Worth noting: security and usability are often a balance. In this case, it looks like they are willing to be quite insecure in exchange for high usability. For a school, this might be warranted.
@EricTowers assuming any of that is even in the system. What's the risk? What could someone with your password do? See his grades? Get your credit card numbers? Transfer your kid's health insurance to their kid? Change his med/allergy list? Pull your kid out of class and deliver him to a creepy guy in a van? Many passwords protect nothing of value.
@EricTowers: I don't follow. Don't "certain staff" also see a student's grades? Don't "certain staff" often have to enter grades into systems online? Can't they just be authorized to do what they're doing because it's part of their jobs and under a legal requirement not to disclose the info? How do you jump to the conclusion that this is necessarily a FERPA violation?
@Mehrdad : I didn't. You should read more carefully. Additionally, you make assumptions about the equality of the set of staff who can see the passwords and the set of staff who are allowed to see *all* records. You also don't seem to understand the breadth and depth of the legal requirements inherent in FERPA.
@EricTowers: I assumed you meant not being able to detect illegal access is a FERPA violation, but if not, then it's even less of a problem. Point is, I don't see what the FERPA issue is. Why can't those sets fundamentally intersect? "Certain staff" could also change a parent's password, log in as that parent, then change it back. If you're thinking "but that will be visible in logs", then okay, the staff's viewing of the passwords could just as easily raise flags in said logs. Now instead of ridiculing my lack of legal knowledge and leaving it at that, it'd be more helpful to explain things.
@Mehrdad : Just because members of school IT are authorized to see the parents password does not mean they are authorized to impersonate them to access records. Of course, there is no way to detect unauthorized use of such credentials. I do wish I could live in your imaginary world where everyone has access but no one would abuse it.
@EricTowers: Are you even reading what I'm writing? Where did *any* of us ever say *anybody* is or should be *"authorized to impersonate"* anybody? You had a problem with IT being able to see passwords, I said that's not an issue because even if they couldn't, they could change the passwords and change them back. Both of those could be prohibited under the same circumstances, and both of them could trigger flags in logs (or not) similarly. And if prohibition isn't enough in one, it's not enough in the other. Are you even intending to understand what I'm trying to say..?
@Mehrdad : You seem to refuse to understand what "incapable of detecting illegal FERPA access" means. Why should I try harder than you to understand you?
@mickeyf "...can hardly be expected to understand the subtleties of security." I'm sorry, but this attitude is part of the problem. When you're doing anything with user data, understanding security is just part of not being incompetent. Period. This isn't even that subtle; this is just having a passing knowledge of the issues.
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.
One might also point them (i.e. the responsible persons at the school district) to the huge leak of passwords from the Adobe site which was made possible because the passwords where not properly (one-way) hashed but because all where (2-way) encrypted with the same encryption key. Also, pointing them to plaintextoffenders.com might be a good idea - because maybe they don't like to end up there.
It's worth noting that it is possible to have the passwords encrypted and the webservice/server not have access to the decryption key. There are a few ways to do this assymetric keys with the reset method using a different server is one. HSM storing the key and being used for encryption/decryption operations is another. Neither of these is likely to be the case here of course.
It is at least possible that not using the terms "hashing" and "encryption/decryption" is deliberate in order *not* to sound too technical, rather than showing a lack of understanding. They are simply using descriptive terms which may be commonly understood by a non-technical audience. @43Tesseracts obviously does know what he's talking about, but the school may not have picked up on that from his email.
@AndrewLeach that is true. Yet, encrypting passwords instead of hashing does point in another direction.
@AndrewLeach: They are using two different terms, "one-way" and "two-way", which clearly correspond to "hashing" and "encryption", and they're using the wrong one. Doesn't change if they say "Irreversible cipher" and "reversible cipher" to sound even more technical -- the behavior is what is important not the terminology.
@SteffenUllrich plaintextoffenders.com seems dead, did they move or are there someone else running it (or similar sites) elsewhere?