138

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?

  • 37
    Can you count? Count on yourself! Don't reuse passwords, use password manager. – el.pescado Nov 23 '17 at 8:03
  • 75
    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". – user114541 Nov 23 '17 at 12:58
  • 14
    "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 – Blorgbeard Nov 23 '17 at 20:32
  • 11
    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? – Myles Nov 23 '17 at 22:04
  • 43
    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. – Eric Towers Nov 24 '17 at 3:08
191

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.

  • 45
    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. – Steffen Ullrich Nov 23 '17 at 6:13
  • 1
    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. – DRF Nov 23 '17 at 7:57
  • @SteffenUllrich plaintext offenders is why I linked the other Q/A – Tobi Nary Nov 23 '17 at 8:02
  • 4
    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. – Andrew Leach Nov 25 '17 at 8:59
  • 6
    @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. – Ben Voigt Nov 25 '17 at 18:19
72

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.

  • 6
    Another great reason to use a randomly generated password for each site. – Dan Nov 24 '17 at 13:06
  • 3
    And how do you stop IT staff from intercepting your password while you login to the service? If the admins want, they can extract your password anyway. I mean regardless of this 3 logins crazy policy. – akostadinov Nov 24 '17 at 13:35
  • 23
    What does client-side hashing accomplish? Whatever you send to the server is the "real" password, whether that's "password" or "5f4dcc3b5aa765d61d8327deb882cf99". – Brian Nov 24 '17 at 16:27
  • 2
    It means the interceptor can't reuse your password on different sites (assuming the website uses some kind of salt that's unique to the site of course). It is not about protection of your account on that site, but on all other sites. – MrZarq Nov 24 '17 at 16:31
  • 12
    Wouldn't hashing on the client side defeat the point of storing hashes of passwords instead of the passwords themselves? If an attacker knows my username and the hash value of my password, they can just send that over and get access to my account without needing my password. – alexgbelov Nov 24 '17 at 19:59
20

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.

  • 24
    "What you can and should do is not trust their system." This should be your default state. Assume all websites are misusing your data and minimize the damage they are able to do with it. – Qwertie Nov 23 '17 at 1:39
  • 12
    "Don't use a password on the school system that is anything like your banking or other passwords" - that sounds weird. If some shady website says "we hash passwords, promise!" do you react "thank God, I can reuse my bank password"? – el.pescado Nov 23 '17 at 7:51
  • 8
    @el.pescado , that may be obvious to us, but many people have never thought about it. Given the huge number of successful Account Take Over attacks that are still ongoing, it’s clear that this advice is still needed. – John Deters Nov 23 '17 at 23:50
  • @JohnDeters I meant that ths advice sounds like "don't reuse passwords on sites that seem to not hash passwords", whereas I think it should be "don't reuse passwords. Period". – el.pescado Nov 26 '17 at 21:16
  • @el.pescado , I understand. I’m trying to write the answer for ordinary people who absolutely do reuse passwords all the time. We can’t realistically hope to change that, so we need to offer answers that have a chance of making a difference. – John Deters Nov 27 '17 at 16:01
14
  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.

  • 1
    While I 100% agree that this is a very bad system I'm not sure I agree with "if they can get your database, they can get the encryption key.". If they stole the database using sql injection that would not enable them to get the encryption key (which lives in the web server). Where senitive data must be retrievable (i.e. not in this instance) encryption can have value – Richard Tingle Nov 23 '17 at 7:43
  • 2
    The probability of collision is not dependant on the input size. It isdependant on the number of inputs, but I don't see how that's relevant. – Martin Bonner Nov 23 '17 at 16:26
  • The probability of a collision is not just astronomically low for small input sizes, it's astronomically low for all input, large or small. The only exception is when using a hash function known to be flawed eg MD5 where finding a collision has been showed to be significantly easier than claimed. Edit: sorry, I realise I've duplicated the above comment – thomasrutter Nov 23 '17 at 22:56
  • 2
    @RichardTingle - Given that the developers of this system clearly have a problem following "best practices", I wouldn't want to trust them not to use encryption in a way that introduces a chosen-plaintext or known-plaintext attack into the system (e.g. using an ECB mode cipher). – Jules Nov 26 '17 at 4:02
  • I agree with the first part of (1) You shouldn't assume your password is ever secure. // The only thing that can be done is to make the system relatively more secure, not absolutely secure. Any complex system will have a backup. With an offline server the backup can be restored and then manipulated at will by the team that design the code and database. – MaxW Nov 26 '17 at 18:02
1

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.

  • "Sending" to you means an automated system. SocEng bypasses this system. You equate processes that are not equal. Again, semantics, but a little confusing. – schroeder Nov 26 '17 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.