91–100 of 181 posts
Earlier quoted context omitted.
You shouldn't send the password because you shouldn't be storing the password. Worries about email security, etc. are secondary.
Yeah, I was surprised to see that this bit wasn't mentioned anywhere. If you are emailing someone their password in plaintext, that means you know their password in plaintext -- which you should not.
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 a…
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.
Earlier quoted context omitted.
"Man In The Middle (MITM)" is the important bit. For example by sniffing the wireless traffic on an unencrypted wlan you can capture entire emails being sent or received, without ever compromising the account.
- Request password reset. - Sniff email with reset link. - Go to reset link before user does and change password.
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.....
Is this offending? Let's also pretend that I have to change this password upon my first login.
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 t…
The dev FAQ should contain information on how to safely (and painlessly) migrate from plain-text/MD5/SHA1 to a more secure algorithm.
Earlier quoted context omitted.
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?
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 r…
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.
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."
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?