12 ms·

But why can't I send people their passwords?

201 points by omervk 12y ago

Hi all, this is @omervk, one of the co-founders and maintainer of Plain-Text Offenders [1]. I've just finished creating two FAQs: One for developers who come to the site and don't understand what's wrong with what they're doing [2] and another for the laymen who want to understand what we're all about and how to protect themselves [3]. The idea is that people could also send these links around to educate others. As HN is one of our main supporting communities, I'd love to hear your thoughts about both of these new pages. [1] http://plaintextoffenders.com/ [2] http://plaintextoffenders.com/faq/devs [3] http://plaintextoffenders.com/faq/non-devs

omervk 12y ago
Clickable links: [1] http://plaintextoffenders.com/ http://plaintextoffenders.com/ [2] http://plaintextoffenders.com/faq/devs http://plaintextoffenders.com/faq/devs [3] http://plaintextoffenders.com/faq/non-devs http://plaintextoffenders.com/faq/non-devs
awsh 12y ago
You've got a typo in the link in dev FAQ #7. Main-In-The-Middle
- vadvi 12y ago
  also this: "[...] or on how the can use them [...]"
  - omervk 12y ago
    Fixed. Thanks :)
- omervk 12y ago
  Fixed. Thanks :)
couchand 12y ago
Question #8 on the non-dev FAQ really should be higher up, like #3. That way the early questions mirror their own thoughts: 1. what is this, 2. but I thought it was secure, 3. what can I do?
- omervk 12y ago
  It's a good thought, but the FAQ starts with what we are, why and how to contribute.
jere 12y ago
>7. Fine, but I still get to send users their passwords once they created them so they don’t forget them, right? Email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Also, users might have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). Would you really like someone to gain credentials to your product when this happens? This is one I always struggled to understand. If email is compromised, the attacker can request and immediately intercept a password reset anyway. [edit: Many excellent points below. I think some of these should be in the FAQ.
- weaksauce 12y ago
  A lot of people use only one password for everywhere... You'd be giving the attacker the keys to the kingdom.
  - jere 12y ago
    This is certainly a good point.
  - kenny_r 12y ago
    Which is still true if you don't know their passwords but if you have their email. You can reset the passwords for just about every conceivable account they have.
    - mechanical_fish 12y ago
      If the password is in the email in cleartext, you don't need an active login for their email. All you need to do is be looking over their shoulder in the cafe, once, when they bring up the email on their iPad.
    - octo_t 12y ago
      Given an uncertain amount of time. Your process requires access to their email account while you go through and reset all their passwords. Whereas if the passwords are in plaintext, you can download all their email and get access at your leisure.
LukeB_UK 12y ago
I disagree with point 11. You shouldn't rely on someone else's service to be the way for users to access yours.
- troels 12y ago
  It's pretty hard not to though. You rely on your hosting provider for service and probably on a multitude of software services too. Of course you have to weigh the value of each further point of failure in your setup, but it's a tradeoff and may well be worth it.
  - sp332 12y ago
    Yeah, but I can switch hosting providers. What happens when I switch login providers?
    - troels 12y ago
      Valid point. Still - that doesn't categorically make it a bad choice. It just weighs a bit heavier on the con side. There are some positive effects of that dependency as well (User trust and convenience).
- adwn 12y ago
  Actually, that FAQ entry itself already counters your argument: "Treat it like you would payment - you wouldn’t write a whole payment gateway like PayPal - but instead use a 3rd party." Where's the difference? By the way, you can always allow users to connect several OpenIDs to a single account – this way, worried users can provide redundancy themselves, if desired.
thesumofall 12y ago
For [11]: I think it makes sense to also highlight other approaches than OpenID such as https://passwordless.net https://passwordless.net which is a sort of way in the middle (disclaimer: I'm the author)
- scrollaway 12y ago
  As a huge supporter of Persona, I am intrigued. Can you sell me on how this may be better?
  - thesumofall 12y ago
    I think Persona is great and can be the right choice for many scenarios. Browser support, the JS requirement, and the reliance on email (whereas tokens can e.g. be distributed via text message) might however be points that convince developers to go with one-time passwords.
    - scrollaway 12y ago
      > Browser support Persona is just a protocol though, it's implicitly supported by all browsers. Though in-browser auth (which is the ideal case) is only in Firefox so far... > JS requirement Granted. Though theoretically, you don't need javascript. > reliance on email Granted again, but this is a completely acceptable tradeoff for 99% of services which will require an email and usually even use it as the user's identification. Still not sold, but I'll keep your solution in mind. Thanks for alternatives! :)
  - thesumofall 12y ago
    Also, Persona still relies on passwords which are usually too weak and re-used across the web
    - scrollaway 12y ago
      No, Persona does not rely on passwords. Persona has authentication providers that rely on passwords.
blueatlas 12y ago
I was a bit surprised by #9.2 - "Don’t put any limitations on the passwords people can use (maximum lengths, disallowing certain characters, etc.)". What's the thinking here?
- scrollaway 12y ago
  What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.
  - pdpi 12y ago
    There was a discussion here a while back on this matter, where I held very much the same position as you. The other guy convincingly proved that adding the "must use at least one each of these character classes" barely reduces the password space, while promoting increased password complexity for those people who would pick the _really_ easy ones.
    - scrollaway 12y ago
      What if I want my password to be "one small step for man one giant leap for mankind" (or something less known)? Do I really have to put a dollar in that to make it secure? Teach good password hygiene. Use keepassx. Use decentralized third party authentication with providers that know what they are doing and use 2FA and such! But password restrictions achieve very little. Let people use their 12345 if they really want, they won't learn by watching the stove but by touching it. Some people are like that and we should educate, not babysit.
      - graylights 12y ago
        Well the other part of weak passwords is for many websites the users care less about account security then the website operator. There are many sites which contain none of my personal info but I have to setup an account just to view website content. If my account gets hijacked, it might be used for spamming. But still If I could make a throwaway account with a blank password I would because I don't care about that accounts security. So surely some restrictions need to be in place if you're going to require signups.
scrollaway 12y ago
Can you please look into Persona and recommend that instead of openid connect? It is a much better approach at decentralized authentication.
- omervk 12y ago
  I have. Please take a look at another comment that explains the issues with it here: https://news.ycombinator.com/item?id=7943695 https://news.ycombinator.com/item?id=7943695
  - scrollaway 12y ago
    I had already replied to that comment.
_mulder_ 12y ago
I'd suggest starting the answer to each question with a clear Yes or No, Right or Wrong so people can skim through. Example: >7. Fine, but I still get to send users their passwords once they created them so they don’t forget them, right? No, Email is not a secure medium.....
- omervk 12y ago
  Good idea. Implemented.
vomitcuddle 12y ago
The dev FAQ should contain information on how to safely (and painlessly) migrate from plain-text/MD5/SHA1 to a more secure algorithm.
- thefreeman 12y ago
  Ack, I accidentally down-voted this comment, someone please right my wrong
- huxley 12y ago
  I think Django's method is a good one to emulate: https://docs.djangoproject.com/en/dev/topics/auth/passwords/ https://docs.djangoproject.com/en/dev/topics/auth/passwords/ A list of password hashers, on successful login the user is upgraded to the top password hasher. Makes it very simple to switch to a new scheme or work factor.
  - masklinn 12y ago
    Outside Django, if you're using Python, there's no excuse to not use passlib[0] whose cryptcontext object[1] handles this situation fantastically: create a cryptcontext with all the hash types you accept as input, and put any "old" hash in the `deprecated` list (or just set `deprecated=['auto']` in 1.6, it'll deprecate any non-default hash — the default hash is the first of the list, or the one passed as the `default` parameter). Then you can just use the relevant method to know that the authentication was successful and you should update the in-db hash: hash = CryptContext( # upgrading from an md5_crypted system ["sha256_crypt", "md5_crypt"], deprecated=['auto']) # in auth code valid, updated = hash.verify_and_update(password, current_hash) if not valid: # error out if updated is not None: # updated is the new hash to set in database [0] https://pythonhosted.org/passlib/ https://pythonhosted.org/passlib/ [1] https://pythonhosted.org/passlib/lib/passlib.context.html?highlight=cryptcontext#passlib.context.CryptContext https://pythonhosted.org/passlib/lib/passlib.context.html?hi...
- omervk 12y ago
  That's a good point, but I think it goes a bit over what I was getting at.
peterwwillis 12y ago
Question 8 on the dev faq should emphasize using multiple layers when doing a password reset, partially to avoid the inherent problems with e-mail security (especially as your last bastion of security). Security questions, browser heuristics, login attempts, out-of-band communication (SMS confirmation code, secondary e-mail account, etc). Question 9 should include a sub-section .3 which explains that if you unrestrict the password field, you need to include a basic password cracker or strength requirement, usually along with a client-side "strength" meter. The backend should reject all simple passwords and the frontend should help the user pick a simple yet strong password. And ideally this page would also link the dev to http://twofactorauth.org/ http://twofactorauth.org/ as an example of how many more places are implementing 2FA. Passwords are dead; long live passwords with 2FA.
- omervk 12y ago
  Re: Q8. Security questions are an anti-pattern and the rest are outside our mandate. I do not claim to have written the penultimate guide to password security :) Re: Q9. Again, that's a great pattern, but is not a requirement to not be on our list. This is linked to from the non-dev FAQ, but I'll make sure to add a section about 2FA to the dev section. Thanks!
  - Flenser 12y ago
    Re: Q9, you could at least put in a link to zxcvb[1] so that they can be aware that it's an issue and that there's libraries for implementing it. [1] https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/ https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...
philk10 12y ago
http://plaintextoffenders.com/faq/non-devs http://plaintextoffenders.com/faq/non-devs "We explain in everything our About page." - doesn't read right, maybe 'we explain everything on our About page"? "your post was deleted with prejudice" ?? needs rephrasing
- omervk 12y ago
  1. You're right. Fixed. 2. Rephrased.
ten7 12y ago
Thanks for doing this, it is greatly appreciated. The list of offenders with screenshots is nice, but what would be really useful is a table that is sortable and filterable so that people (i.e. me) can find out if any of our vendors are offenders. Also, a JSON API would be slick too. Just ideas.
- omervk 12y ago
  Soon :)
john2x 12y ago
Is a plaintext (heh) list of all the sites available?
- omervk 12y ago
  Soon :)
eldelshell 12y ago
This is something that came to mind while reading the comments: Why should me, the owner/developer of some service, care if somehow your password is stolen/guessed by any mean? I'm not saying we shouldn't take care of our users, but how's our fault that their email is hacked? We can't do anything to protect against this and placing more complex policies would hurt users who have enough common sense to this properly and expecting the same from us. P.S. I'm in no way saying to to ditch all security procedures we can, but to one point security is about trust, and if you can't trust your users to keep their freaking passwords and email accounts secured, then hell with them. Put it in plain text in your TOS and be done with it.
- marcosdumay 12y ago
  Do you have any idea how email works? You could as well just publish your users passwords at your front page, and claim that if a user has a password compromissed because of that, it's his own fault, you should be able to trust them not to use insecure services.
- omervk 12y ago
  Because then users would lose faith in your service? Also, your service can then be abused. Think about a hacker ramping up charges on a credit card, only to have fraud detection activated and you losing money (and getting worse rates in the process).
- cincinnatus 12y ago
  And when your server is inevitably compromised and your users passwords stolen from you due to your lack of dillgence and used to compromise logins on other services, what then? Still their problem?
omervk 12y ago
Wow, thanks for all of your points and suggestions! Unfortunately, I'll only be able to attend to them in an hour or so, so please bear with me and I promise personal attention to each any every point made here.
makmanalp 12y ago
Your non-devs FAQ is still not quite informative. You still don't explain to laymen /why/ what the sites are doing is wrong, you just say "You should never see your password". edit: Maybe something along the lines of: > Modern cryptography allows websites to save passwords in a form that is un-decryptable even to the site itself. This works because to check the validity of logins, the unencrypted (plain) version of the password is never needed. The fact that a site stores the password in a decryptable format and decrypts it to show it to you means that an attacker could potentially decrypt the password in the exact same way. Or even worse, maybe they never encrypt it in the first place! This potentially compromises the safety of the password you use because it lets an attacker steal your password.
- omervk 12y ago
  Thanks, I've added wording for that.
  - ufo 12y ago
    I prefer makmanalp's explanation to the wording you are using right now. It emphasizes that hashing is an one-way operation and "encryption" or "scrambling" are more familiar and less abstract than "representation". I know its not an accurate usage of the terms but this is the layman FAQ and we could always add a link to a more in-depth explanation using the correct terminology (hashing, salts & key strength).
- ajanuary 12y ago
  That's a pretty technical explanation. I think something like this would suffice: > If the website can pull out your password to show it to you, an attacker can pull out the password to steal it. As ever, the issue is explaining hashing.
  - prawks 12y ago
    I like this description. I don't know that you need to explain hashing to laymen, though. Hand-waving is acceptable when communicating to people who aren't skeptics (laymen). If they're really interested in fact-checking you, they can do so on their own time, or you can provide links to detailed explanations. "It is possible to store passwords in a way that the website cannot see your password, but can still verify that a password entered by you checks out." (trust us, after all you're trusting that we know what we're talking about by reading this stuff)
bdg 12y ago
Creating an FAQ for these companies would be useful. Something to arm the devs who work at these places with something when they go to management who's reaction is "yeah I know it's bad.. but... like, we have important shit to do."
- omervk 12y ago
  What would you suggest?
  - jchung 12y ago
    Assume the company is unaware that their developers have implemented the password this way. The FAQ for the company should highlight the exceptionally high cost of losing customer data, the distraction for their team from dealing with any breach, and the incredibly low cost of making the fix. The call to action could be for them to email their developer a link to your dev FAQ, demanding a fix.
    - omervk 12y ago
      That's a great idea! I'll add "I've been listed! What do I do?" to the FAQ. Thanks!
jscheel 12y ago
Our healthcare provider is storing passwords in plain text. When I went in for my health screening, they had everyone's forms printed out, with our passwords written on sticky notes attached to the front. Hundreds of people's health data, wide open for the taking. I was beyond pissed. Then I found out that they don't use ssl on their service, and the passsword can be retrieved at the click of a button. Ended up speaking with a C-level about it. Her response was that they are perfectly within HIPAA compliance, and that she would have to talk to their CTO about any other problems with their data security. Looking at the HIPAA, I have to say, it's not very clear on the need for hashing passwords. Still, I reminded her of the massive liability they are opening themselves to. She promised to get back in touch with me, but I haven't heard anything since (imagine that).
- moistgorilla 12y ago
  Lol, my dad is an endodontist and he hasn't made his website interactive (patient accounts, interactive appointment scheduler, interactive referrals) yet because he can't afford a webdev that would make it secure (salting/encryption). My dad is an endodontist with zero software/web experience and even he knows not to keep passwords in plaintext and to use ssl. I'm only a CS undergrad and I'm learning webdev so I can implement it for him but I still know to hash and salt your passwords. The fact that people implement these critical systems (and get paid for it) without knowing basic practices makes me worry about the future.
- Jemaclus 12y ago
  My 401K company, Kibble & Prentice, does the same thing. They make you call a phone number if you forget your password, and then the operator reads the password out loud to you over the phone. Freakin' amazing. I told HR and they said they'll change companies, but that was six months ago, so... who the hell knows.
daddykotex 12y ago
Let's say I register for a Web Hosting solution. And then I receive a email containing a username built upon the information I gave them and a generated password to access the cPanel. Is this offending? Let's also pretend that I have to change this password upon my first login.
- omervk 12y ago
  Yes, because you might not be the first to use that password.
aturek 12y ago
I've been trying to learn the best practices on password "storage" and verification lately. I thought this was a really good step-by-step technical breakdown of the right way to hash passwords (I have no opinion/knowledge of the hashing algorithms in the article, but I've found a lot of other positive mentions of PBKDF2, bcrypt, and scrypt) http://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/ http://nakedsecurity.sophos.com/2013/11/20/serious-security-...
- omervk 12y ago
  I'd appreciate it if you could post this as a comment to the Dev FAQ page :)
TallGuyShort 12y ago
This is really good, and I applaud your efforts in that site in general! My one suggestion would be to explain the term "representation" a little better to non-devs so they understand why the secure technique is secure. I like to use the term "one-way encryption" so that it's clearly not some simple derivation of a password, but a mathematical process with proven difficulty and uncertainty when reversing.
- omervk 12y ago
  I thought of my mom and dad reading this and what they would best understand. I'm worried using something like "one-way encryption" would have their eyes glaze over :)
  - TallGuyShort 12y ago
    Probably. What about something to the effect of just adding, "The representation is created by shuffling and encrypting the password over and over so there's no way to reverse the process" or something like that?
bwy 12y ago
This isn't really addressing the main issue. You need to emphasize and just drive the point home that people should not even be STORING plain text passwords. Anywhere. Get them to understand that they don't want to, and shouldn't, know anyone's password in plain text, and how. It's a very counter-intuitive concept that makes sense once explained. EDIT: Just saw @ajanuary's child comment on the top-voted parent. The point exactly.
7952 12y ago
It is worth remembering that reset links should also be hashed. If the database is compromised the reset ID can be retrieved without needing access to the users email.
peg_leg 12y ago
You shouldn't be able to see their passwords in the first place, let alone send it to them. You should only store a one-way encrypted string based on the password they typed.
a1a 12y ago
>>(Question 5) What? No! Why use algorithms that have been broken for years? It’s ridiculously fast to break both, along with many other simple algorithms. I'd remove the emphasized text. Yes they are vulnerable to collision attacks but that's completely irrelevant in this context.
mcovey 12y ago
instead of "shittysecurity.com" you might want to use something like "example.com", for one because some people will see it as inflammatory, and because some eager devs might be presenting this to bosses who will take offense, and based on that emotion, decide the whole thing is bullshit.
- omervk 12y ago
  Good point.
pornel 12y ago
The dev FAQ perpetuates a common misconception about "broken" MD5 and SHA1. MD5 and SHA1 are bad for password hashing indeed, but that's because they're fast, not because they have known collisions. Collision attack has nothing to do with password security. For passwords the relevant attack is the preimage attack, which is a different thing and there are no feasible preimage attacks against these hashes (yet, of course).
pornel 12y ago
The dev FAQ perpetuates a common misconception about "broken" MD5 and SHA1. MD5 and SHA1 are bad for password hashing indeed, but that's because they're fast, not because they have known collisions. Collision attack has nothing to do with password security. For passwords the relevant attack is the preimage attack, which is a different thing and there are no feasible preimage attacks against these hashes (yet, of course).
Frozenlock 12y ago
I don't see how sending a reset link is secure. Wouldn't anyone intercepting the email be able to use the reset link themselves and gain access to the account?
- lotyrin 12y ago
  Reset links can at least time out, passwords generally don't. Providers should send you notifications when you reset your password, they generally don't when you just log-in like normal.
tptacek 12y ago
The "Don't Use Bcrypt" article isn't a good source; the headline message you've taken from it isn't accurate. In fact, bcrypt is significantly better than PBKDF2, and PBKDF2 (with normal parameters) is probably the "least best" of the mainstream options for password hashing. By citing an inside-baseball controversy, you're making it harder for developers to do a good job storing passwords, because you're creating the impression that developers need to carefully choose which password hashing algorithm they use, and be careful about making the wrong choice. In reality, what developers need to be careful about is choosing a password hashing algorithm, and not a general-purpose cryptographic hash. The right message is that PBKDF2, bcrypt, and scrypt are all fine options. So my feedback is that your developer FAQ is trying to be a little too clever for its own good. I'd revise it.
- omervk 12y ago
  Thanks for the feedback. I went back to the article (which we started linking to a couple of years ago) and saw the comments and, along with what you wrote here, removed the preference of scrypt and PBKDF2 over bcrypt.
geoffsanders 12y ago
Or don't use passwords? https://launchkey.com https://launchkey.com :)
- omervk 12y ago
  I'd appreciate it if you could post this as a comment on the page itself. :)

personZ 12y ago

You'd be giving the attacker the keys to the kingdom. No, the people who use a common password gave out the keys. There is simply no excusing it. The apologism for it has to stop. NEVER use the same password across multiple services. If one service gets compromised, the extent of their culpability is their own service. Anyone whose password exposes other things was the cause of their own demise. EDIT: I will not back down from this (and you shouldn't feel too ashamed for reusing passwords and falling in the above buckets, desperately hitting down arrow. Just correct your mistakes). It is utter idiocy to constantly defend the habit of shared passwords, when people give it to services of zero trust, and with unknown habits and practices. When some service of no consequence stores your password in plaintext, that is them being dumb. If you then complain because it's the same password used elsewhere, that is you being dumb.

unreal37 12y ago
I'm not going to presume to know anything about you, but as soon as your system interfaces with human beings, your system needs to adapt to human nature. You can't say "there's no excusing it" and "cause of their own demise". Humans act as humans tend to do - why should the security of your system rely on humans changing their natural behavior?
- personZ 12y ago
  You can't say "there's no excusing it" and "cause of their own demise". Yes, you absolutely can and should say that. This isn't human nature, but is simply accepted and defended behavior that gets caught out again, and again, and again. I have absolutely no doubt that many visitors to HN are guilty of this, and instead of confronting the reality of their insecurity, pretend it's someone else's fault. Each time some random, irrelevant message board has a password exploit, everyone who should know better rushes forth to pillorize the operator because of the greater danger, yet the operator may have been sharing those passwords on the black market for time eternal. The operator may have been putting their plaintext backups on a compromised FTP site for years. They may have engaged endless contractors who made their own backups and are busy buying stuff on Amazon for it. But instead we argue pretend security measures, when the horses have not only bolted, they're several states away. It is complete idiocy to use passwords across services. Utter insanity. It is the worst possible practice imaginable, and is never, ever excusable. If you used the same password across sites, you simply must assume that since day one it has been compromised, and it is your own doing. But here we excuse it. And then, in excusing it and defending it and supporting it, claim that it's "human nature". It isn't human nature at all. How To Hack 60% of Hacker News: Create a service requiring users to create logins, submitting it as a show HN. Harvest email/passwords from very foolish people and enjoy their access everywhere else.
  - deathcakes 12y ago
    I agree with you - using the same password in multiple places is a dumb thing to do. However, you seem to be totally missing the point made in the previous post, namely that people are, on the whole, pretty dumb. The vast majority do not share your understanding of computers and security and hence see no real issue, although this is very very slowly changing. I disagree entirely with your statement that: "This isn't human nature, but is simply accepted and defended behavior that gets caught out again, and again, and again." This is patently false - remembering a different password for every single system, device and site you interact with is not a feasible proposition for the vast majority, especially if you require these passwords to be in any way meaningfully secure. There are ways of sidestepping this problem, such as 1password and the like, but the ones that are most seamless are paid for services and hence the adoption rate among technically illiterate people is pretty small (I'd imagine, no stats here). The real issue is that passwords are a broken way of authenticating. End of. Passwords that are easy to remember are trivial to crack, and passwords that are difficult to crack are hard to remember. This is the issue here. People may do dumb things, but it is far easier to change your system than it is them.
    - personZ 12y ago
      However, you seem to be totally missing the point made in the previous post, namely that people are, on the whole, pretty dumb. The whole discussion revolves around a fundamental principal that is simply broken to begin with, akin to "How to try not to die when you eat rotting meat". Don't eat rotting meat. Use a fridge. Etc. In the case of passwords- -Use a shared authentication platform -or on sign-up implore that your users do not use a shared password. Education -or offer, or force, a generated password But instead we'll discuss the risk that shared passwords get lost, when they were in the wild the moment you used them on a second site.
      - deathcakes 12y ago
        This is a disingenuous analogy - the reason people keep eating rotting meat is because there isn't a usable alternative for the vast majority. Fridges are unknown, to hopelessly overload the metaphor, to the masses and those that are aware of them are reluctant to shell out for the cost. The problem needs to be solved at a more fundamental level - people should not have to be forced to perform a function that they are demonstrably bad at. Mitigation strategies like having randomised passwords and storing them in a shared authentication platform are only masking the reality that passwords are a bad way of performing authentication. Not that I'm clever enough to come up with an alternative mind you, and not to suggest that I don't agree with your premise that using a password in multiple places is a bad idea.
mreiland 12y ago
I re-use passwords, but only for things I don't care about. Not everything is critical, if someone gets into my HN account, for example, I'm not too fussed about it. It sucks, but whatever. If someone gets into my bank account... different story. It isn't that people re-use passwords that's the issue, it's that they do it for shit that actually matters.

jaredmcateer 12y ago

Another thing to consider is if your email provider's offline backups get jacked in transit would you rather your emails contain your plain text passwords or links to a password reset with expired tokens?

x86_64Ubuntu 12y ago
I have never thought of that, ever. I'm not being sarcastic. Usually I think of email as existing on some secure server, I never thought that backups are kept, maybe in a different medium which is then open to vulnerabilities.
- jwl 12y ago
  It is frighteningly common to neglect backups when thinking in security. I have seen a couple of examples where the technical aspects of security with good firewalls, good access control to servers and so on were in place, but backup media could still be found laying around for everyone to grab.
- mechanical_fish 12y ago
  This is why, for example, Amazon S3 has a little checkbox on each bucket to encrypt the contents of the bucket. At first glance this might seem a little silly. Amazon has the key. (You don't even get to see the key yourself.) So Amazon can read all your data. And every time you read from the bucket it's automatically decrypted, so the encryption won't protect you from anyone who has somehow achieved permission to read your data. But that's not the point. The point is to protect against attacks like "I found this pile of dusty drives stacked in the maintenance closet at Amazon," or "I went digging in the local dump near an Amazon data center and unearthed this hard drive, and look what I found backed up on it."
  - herge 12y ago
    I'd even make the effort of encrypting yourself any data you want to protect that you send to s3. GnuPG is not that hard to use with RSA.
    - mechanical_fish 12y ago
      Yeah, I go back and forth on that one. The problem is that the key management is crucial. Slip up and lose your key and your data is toast. Obviously this also applies to Amazon, but they have more resources, better incentives, and one million times the operational experience with their key management system than I'll ever have with mine. Frankly, my clients should bet on them over me. Now, one good idea might be to redundantly back-up Amazon's backups at some other host, using GPG to encrypt those. This ensures against Amazon encryption errors, billing errors, mistyped legal injunctions, Jeff Bezos declaring you his personal enemy, et cetera. This may be obvious, but rolling my own at-rest encryption is not going to significantly protect my data from an attacker who works inside Amazon, nor from an attacker who roots my instance. If the keys are in the cloud, the keys are in the cloud. UPDATE: oh, yeah, I forgot the use case where you are writing to s3 from outside Amazon's datacenter over HTTPS. Okay, that is a much stronger case for GPG in advance. It wouldn't matter if we assumed that TLS always worked. But this is TLS. Does your upload client check the certificate chain? So many of them do not. I sure hope Amazon's CLI client does.....
  - 15characterlimi 12y ago
    I just recently got this email from AWS: Dear Amazon S3 Customer, Amazon S3 now supports server side encryption with customer-provided keys (SSE-C), a new encryption option for Amazon S3. When using SSE-C, Amazon S3 encrypts your objects with the custom encryption keys that you provide. Since Amazon S3 performs the encryption for you, you get the benefits of using your encryption keys without the cost of writing or executing your own encryption code.
    - chris_mahan 12y ago
      Wait. how exactly do you transfer the encryption key to amazon? And do they keep your key? How long?
      - angersock 12y ago
        Presumably another key? Look, it's keys all the way down. Beneath that, wiretaps.
- jaredmcateer 12y ago
  I'm not even giving a hypothetical scenario. It's no longer fresh in the minds of most people but years ago Reddit used to store their passwords plain text for the convenience of being able to send them to the user, instead of implementing a password reset mechanism. One day their hosts backup tapes were stolen out of the back of a truck. Now they salt+hash their passwords.
omervk 12y ago
Thanks, I've added that to the FAQ. :)

furyg3 12y ago

If someone wants to use a 250 character truly random password with crazy characters, let them do it. If they used a long password with an excellent mix of upper-case, lower-case, and special characters, but no numbers, it's a good password, take it. I had a password for a credit card account which could not be more than 8 characters and couldn't contain 'special' characters or punctuation. This was probably done to either make the password human readable (over-the-phone, horrible idea), or because of some legacy system on their end. At some point the organization got smart and made a minimum of 6 characters, of which two needed to be numbers (but kept the other restrictions). This effectively narrows down pool the possible passwords for an attacker to guess, the opposite of what you want to do.

nly 12y ago
While it's true their changes made the key space smaller and, even with a good KDF, 8 chars was never long enough to begin with, the reduction is negligible. Assume 36 char (alphanumeric, case insensitive) passwords: Originally: 36^8 + 36^7 + 36^6 + 36^5 + 36^4 + 36^3 + 36^2 + 36 2,901,713,047,668 possible passwords ~41.4 bits After: (36^8 - 26^2 * (8*7)/2) + (36^7 - 26^2 * (7*6)/2) + (36^6 - 26^2 * (6*5)/2) 2,901,650,810,624 possible passwords still ~41.4 bits Only 62,237,044 possibilities eliminated. Length is the most important factor, so this was probably a good decision if most of their users were using <= 6 char passwords, or not using numbers at all. And frankly, the financial sector should be using HSMs anyway, making weak KDFs irrelevant.
moistgorilla 12y ago
Making the minimum password length 6 characters reduces the possible outcomes by a negligible ammount.
stonemetal 12y ago
Have fun running bcrypt on 100TB of /dev/urandom. Insanely large password limit? Sure sounds like good business to me. No password length limit? Sounds like a DOS attack waiting to happen.
- omervk 12y ago
  What would you suggest as a sane upper bound?
  - stonemetal 12y ago
    No idea, especially as pass phrases have become more popular the max length of a password that you might see in the wild has gone up quite a bit. Lets say someone is willing to type for 1 min to login to a site. According to Google the fastest typing speed recorded is 216 words per min. According to the words per min Wikipedia entry a "word"(They give examples of "I run" counts as one word, but "rhinoceros" counts as 2) is 5 characters long so that gives us a max password length of 1080 characters. According to wikipedia War and Peace is just shy of 600 thousand words long or approximately 3 million characters. Therefore 1000 is a good minimum max length but 3 million is way to long.
  - TallGuyShort 12y ago
    const int PW_MAX = strlen("correct horse battery staple")
  - masklinn 12y ago
    You're probably good with 1k FWIW Django added a 4k limit (4096 bytes) last September: https://www.djangoproject.com/weblog/2013/sep/15/security/ https://www.djangoproject.com/weblog/2013/sep/15/security/

drewcrawford 12y ago

I think this is easier than it sounds. To a layman, when they type in their password, they are not thinking about how it would be implemented. The idea that "oh, somebody is doing a string compare against a password in the database" is not something that would enter their mind. That is baggage that software developers may have, but ordinary people have not been primed in that way. Ordinary people are going to be thinking about a key in a lock. Does the lock on your house store the key inside? Maybe in some kind of information-theoretic sense but in the ordinary meaning of the word, no, it has a representation (that may not even be sufficiently specific to recover your key exactly). And if you lose your key you don't break into the lock to recover it--you call a locksmith to replace the lock, and get new keys. That right there is an intuitive understanding of both hashing and good security principles that goes surprisingly far.

ajanuary 12y ago
Absolutely. I wasn't really clear. I didn't mean it needs an explanation of hashing. I meant there needs to be some short answer to the question of "if they can't pull out my password, how do the check it?" I don't think people are thinking about keys and locks. Passwords are a thing that existed before computers and that people understand perfectly outside of an IT context. Spies in films use secret phrases to prove they're the contact, kids use passwords to gain access to the clubhouse. But in all these non IT contexts the person checking the authentication knows the shared secret, so it's obvious how they check it. If my mental model is "I've arranged a secret password with this website that proves I'm really me", then my first question when told the website doesn't know what secret password is "well how does it know that the password is correct?". The best I've been able to come up with today is a somewhat lengthy metaphone with color mixing. [Edit] Having said that, I just went and talked to my technical literate non programmer wife and she used the key and door analogy.

PwdRsch 12y ago

It is complete idiocy to use passwords across services. Utter insanity. It is the worst possible practice imaginable, and is never, ever excusable. It's one thing to argue for improving people's password practices, but please don't pretend that there's no reason for their behavior. The vast majority of people who share passwords between sites experience no repercussions from their choice. And choosing not to create a new password for every site saves them time and potential frustration. That's the human nature part, to assess the risk of behavior and change it only if future experiences show that the costs associated with that behavior are too high. Since most people don't experience the disadvantages and do experience the benefits this behavior continues. We can encourage more people to avoid this behavior by explaining the potential impacts and providing accurate estimates of the risk they're taking. We can offer alternatives to password reuse, like using a password manager. But ultimately they are still going to weigh their perception of the risk and benefits to make their own decision.

personZ 12y ago
The vast majority of people who share passwords between sites experience no repercussions from their choice. More accurately, they have no awareness of the reprecussions from their choice. Yet endlessly on HN we hear stories of mysterious iTunes access, Steam takeovers, even Amazon AWS account compromises. It is no big mystery when this happens given this common, grossly insecure behavior. But ultimately they are still going to weigh their perception of the risk and benefits to make their own decision. I absolutely agree, absolutely and completely, but think that the risk portion is hugely underestimated. Among people who should know better there is a tendency to under-estimate what is an enormous, worst-possible-exploit problem. No one ever talks about education. No one wastes time trying to help users enjoy better behavior. Instead we argue about whether some site operated by an unknown number of people of unknown trustworthiness, on a platform that might have been exploited and owned by hacker groups for years, properly hashed our password after we passed the keys to all services through plaintext. It is insanity.
chris_mahan 12y ago
I'm a software developer, but I'm done trying to remember passwords for every single site. What do I do? I just don't use the sites. I've restricted, and continue to pare down, the sites that I use on the internet. It's the truth. I do keep my amazon.com account, so I can order paper and cardboard books the local bookstores don't carry, and read them on the sofa at my house, next to my floor lamp.
- weaksauce 12y ago
  there is a few solutions. use a password manager like lastpass or keepass or something like that. it generates passes for you and you don't have to remember them.(bonus: it logs you in automatically if you go to the vault and click login) use throwaway passwords for one off services and just use the password reset feature when you want to use it.
  - chris_mahan 12y ago
    Except, well, I use several computers, plus smart phone.
    - weaksauce 12y ago
      lastpass works on all of them.