6 ms·
The case where you get your new password by mail when you just changed it does not necessarily mean it is stored in plain text. They could keep it around in mem
by Monkeyget 12y ago
The case where you get your new password by mail when you just changed it does not necessarily mean it is stored in plain text. They could keep it around in memory just long enough to send it by mail.
Doesn't mean it is a good idea though.
- pjscott 12y agoThere are some ways to do that sort of thing safely, for some value of 'safe', but they're non-trivial. Sticking the plaintext passwords in a database row is trivial. Which do you think is more common? :-(
- zxcdw 12y agoBut that has nothing to do with the fact that just because the site emails you a password doesn't mean that they store the password in plaintext. The catch here is that if they email the password upon the user having entered it (made an account or changed their password, or had password generated for them, ...). If user requests a lost password and it's returned in plaintext, then one can be sure that the password isn't being stored in proper way. HN does this too, by the way. If you request a new password for an account, it's being sent in plaintext. No problem here, what comes to storing it.
- heinrich5991 12y agoNo problem here? It goes through so many servers, unencrypted…
- gpvos 12y agoIt's no problem, as long as it's a one-time-only password and has a limited lifetime (ideally only a day or so). It's similar to a password reset URL, which is also a password equivalent, but only usable once. At least it's better than asking for your mother's maiden name.
- deleted 12y ago[deleted]
- rimantas 12y agoWell, what would you do with an encrypted password sent to you by email? How do you propose to solve this? Using password reset links instead changes very little.
- __david__ 12y ago> Using password reset links instead changes very little. Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.
- fooyc 12y agoOdds are that you registered over plain HTTP anyway
- personZ 12y agoHow many servers does it go through? Mail in the real world, today, is virtually always source server -> destination MX server. There was once a fanciful era when occasionally offline servers passed off to various smarthosts, and this was the big fear about email, but that is no longer the case. HN passwords are not high security. If we lose an HN account, not only can it be easily restored by an admin, it's really not a huge loss - start again. There doesn't need to be extreme practices. Oh, you use the same password across sites? (which is the source of 99% of password security concerns). That is crazy, and you shouldn't do that. That's on you. (You being the conceptual person up in arms)
- runn1ng 12y agoI am not sure what you mean. If you are changing the password/registering, the password is in plaintext in the memory on the server anyway; it just has to be. So they can just mail it to you.
- __david__ 12y agoThat doesn't mean it's good practice. In fact it's a pretty bad practice.
- kremlin 12y agoThere's a fairly trivial way to do it in Django I think (whether it's still safe to send an email with pw in plaintext is still questionable at best): Say a user forgot their password and they click some link to reset their password: Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.
- marcosdumay 12y agoThe Django builtin functionality is more secure than that. Do not send passwords in email. You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.
- agildehaus 12y agoAnd be sure to destroy the token immediately after the user resets, and also after a reasonable time period regardless if it was used (24hrs seems fine to me). Otherwise the email could be found later and used to gain access.
- TomGullen 12y agoJust a point, this is pretty much the same as sending a plain text one use password.
- kremlin 12y agoI wasn't suggesting to do this and I have never done this, just pointing out that it is technically easy. I don't really know why I got a downvote for that
- fooyc 12y agoThat's really trivial, and many web applications work this way: email = input.email plainPassword = input.password hashed = hash(plainPassword) saveToDb(email, hashed) sendGreetingEmail(email, plainPassword) Emailing a plain text password during registration is not the same as storing it forever in a database.
- uulbiy 12y agoIt's not the same but there are other security issues. The server to server transfer of the email message might not be encrypted (it might be if both have TLS extensions enabled). So, emailing plain text passwords is always a bad idea even if it's not stored as such.
- fooyc 12y agoI agree that from a security standpoint it's better not to send the password in plain text at all. But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.
- jonahx 12y agoThose should be listed too. I'm not sure I follow your point: Because there exists this other really bad but common practice, why are we harping on this bad practice?
- hackinthebochs 12y agoBeing overly concerned about having your email sniffed as its passed along internet peer is just misplaced anxiety. Anyone who can successfully sniff your password from your email in transit can already own if they chose to. The convenience factor of having your password emailed and having a record of it in many cases trumps this concern. "But what if someone hacks your email, they know all your passwords!" What if someone hacks your 1password account? It's the same exact scenario. Having a single point of failure that one can be extra vigilant with guarding is much better than the alternative of having a hundred unique passwords one must remember.
- CiaranMcNulty 12y agoEven if it's not stored at their end in plaintext it's a security issue that it's emailed in plaintext.
- aunty_helen 12y agoThere was an article on HN in the last week (or so) claiming that both inbound and outbound encryption of email was happening. http://readwrite.com/2014/06/06/google-gmail-encryption-fail-comcast#awesm=~oHUqmuxHLxmbAM http://readwrite.com/2014/06/06/google-gmail-encryption-fail... Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.
- gpvos 12y agoIt happens, but way too little.
- jedbrown 12y agoUnfortunately, STARTTLS is subject to service degradation attacks and it is very common for email servers to use unsigned keys. Simply enabling STARTTLS protects against passive attacks, but until email servers refuse connections that do not create a TLS session with proper certs, email will remain subject to MITM attacks. Meanwhile, this failure mode is a usability problem for email. My experience with notifying companies about insecure email practices has been extremely disappointing, even among those that should know better (like national labs and financial institutions).
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]