141

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?

Stevoisiak
  • 1,515
  • 1
  • 11
  • 27
43Tesseracts
  • 1,083
  • 2
  • 6
  • 6
  • 37
    *Can you count? Count on yourself!* Don't reuse passwords, use password manager. – el.pescado - нет войне Nov 23 '17 at 08: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". –  Nov 23 '17 at 12:58
  • 1
    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... – Damon Nov 23 '17 at 14:35
  • 1
    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. – O. Jones Nov 23 '17 at 15:03
  • 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
  • 4
    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. – thomasrutter Nov 23 '17 at 22:46
  • 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](https://www2.ed.gov/policy/gen/guid/fpco/brochures/parents.html) access to protected education records and personally identifiable information by said staff. – Eric Towers Nov 24 '17 at 03:08
  • 5
    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. – emory Nov 25 '17 at 11:06
  • 3
    @emory School Board IT staff != teaching staff – schroeder Nov 25 '17 at 17:56
  • 2
    @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. – Ben Voigt Nov 25 '17 at 18:16
  • 1
    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. – Cort Ammon Nov 27 '17 at 01:18
  • 1
    @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. – Harper - Reinstate Monica Nov 27 '17 at 03:43
  • @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? – user541686 Nov 28 '17 at 02:52
  • @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. – Eric Towers Nov 28 '17 at 03:17
  • @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. – user541686 Nov 28 '17 at 04:07
  • @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. – Eric Towers Nov 28 '17 at 04:24
  • @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..? – user541686 Nov 28 '17 at 04:28
  • @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? – Eric Towers Nov 28 '17 at 04:33
  • @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. – jpmc26 Nov 28 '17 at 16:01

5 Answers5

192

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.

psmears
  • 900
  • 7
  • 9
Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • 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](https://arstechnica.com/information-technology/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/) 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](http://plaintextoffenders.com/) might be a good idea - because maybe they don't like to end up there. – Steffen Ullrich Nov 23 '17 at 06: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 07:57
  • @SteffenUllrich plaintext offenders is why I linked the other Q/A – Tobi Nary Nov 23 '17 at 08: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 08:59
  • @AndrewLeach that is true. Yet, encrypting passwords instead of hashing does point in another direction. – Tobi Nary Nov 25 '17 at 09:00
  • 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
  • @SteffenUllrich plaintextoffenders.com seems dead, did they move or are there someone else running it (or similar sites) elsewhere? – ZN13 Nov 29 '17 at 12:36
  • @ZN13 it’s not dead, they just switched format to a tumblr. – Tobi Nary Nov 29 '17 at 12:38
  • @SmokeDispenser Last post was June 3rd, 2016, thats over a year ago, a month ago [in the comment section here](http://plaintextoffenders.com/ask) a guy was asking why his post which he submitted months ago wasn't showing up. There are other comments elsewhere on the site asking if it's dead. – ZN13 Nov 29 '17 at 12:42
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.

MrZarq
  • 821
  • 5
  • 3
  • 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
  • 1
    Well, in my opinion passwords should be hashed on client-side. You can verify if this happens by inspecting the data that is sent to the server. – MrZarq Nov 24 '17 at 13:42
  • 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
  • @akostadinov The site can be programmed such that passwords are not put in the logs or otherwise made accessible short of copying the memory at the exact point the server is processing the request (which itself can be prevented with proper physical controls). All of this requires that you trust the site to protect your password, but if you don't we're back to square one anyway. – IllusiveBrian Nov 25 '17 at 00:59
  • 2
    @akostadinov Yes, you have to trust the app and staff is not logging your password in plain text. The fact the staff *told you* that they can access the plain text password still undermines that trust. – jpmc26 Nov 25 '17 at 09:35
  • @jpmc26 `For support reasons, the parent password is visible to certain staff until the parent has successfully signed in n times.` Can you describe how confident you are in them as a function of n (assuming all other conditions are constant) as n goes from 0, 1, 2, 3, 4, 5, ... Does n really matter? – emory Nov 26 '17 at 02:06
  • @emory I'm referring to the fact that the web application *always* has access to the plain text password, no matter what protections are in place. (Even if you do client side hashing, that really just changes what the password's value is.) You have to trust that the web application does not log this information somewhere. That trust drops to zero once they tell you they have access to your password, but I am saying that at some point, there is no technical protection and trust is the only option. – jpmc26 Nov 27 '17 at 21:55
  • 1
    @MrZarq Thanks for the reply. That's a very interesting point; I think it's the first instance where I can see the use of javascript as contributing to security vs. only contributing vulnerabilities. – Brian Dec 14 '17 at 18:30
19

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.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • 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 01: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 07: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
  • It is hard to word this correctly. I use a password manager so the probability that the school password is exactly the bank password is small but greater than zero. The password manager does nothing to enforce password dissimilarity other than probability. – emory Nov 27 '17 at 23:10
  • @emory, the chances of a good password manager generating a collision are negligibly small - so small that they are not worth discussing. A bad password generator, on the other hand, is risky far beyond mere chance. – John Deters Nov 28 '17 at 01:16
  • @JohnDeters I agree. The verbiage "Don't use a password on the school system that is anything like" suggests something that I don't think you mean. It is hard for me to think of better words. – emory Nov 28 '17 at 22:31
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.

Machavity
  • 3,766
  • 1
  • 14
  • 29
  • 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 07:43
  • 2
    The probability of collision is not dependant on the input size. It **is**dependant on the number of inputs, but I don't see how that's relevant. – Martin Bonner supports Monica 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 04: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.

gnasher729
  • 1,823
  • 10
  • 14
  • "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 08:32