Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

But why can't I send people their passwords?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 181 posts

Re: But why can't I send people their passwords?

#31

Post by blkhawk »

jere wrote: post #5

> 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 y…

>This is one I always struggled to understand. If email is compromised, the attacker can request and immediately intercept a password reset anyway.

Not really the main issue - if you always send the password the Thief controlling the email does not even need to reset the password. he can get in without leaving any trace at any time. It also allows the collection of all the Passwords from all the users in bulk. And if your users are reusing their passwords everything else is open too.

Sending the Password is just a stupid policy. Its up there with restrictive Password requirements and Server-side unhashed Password storage.

Re: But why can't I send people their passwords?

#32

Post by gpvos »

powatom wrote: post #27
jere wrote: post #5

> 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 y…

True - but you can add an additional layer of security to the password reset request if this is a concern, such as personal questions.

Using personal questions for security is the worst thing ever.

Whenever I encounter them, I paste the output of "dd if=/dev/random bs=1k count=1 |uuencode x" into the field.

Re: But why can't I send people their passwords?

#33

Post by furyg3 »

blueatlas wrote: post #20

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?

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.

Re: But why can't I send people their passwords?

#35

Post by pdpi »

scrollaway wrote: post #24
blueatlas wrote: post #20

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?

What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.

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.

Re: But why can't I send people their passwords?

#36

Post by asuffield »

slight wrote: post #12
Mithaldu wrote: post #8

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.

The key difference is that capturing a plaintext password means the user and attacker both share a password without the user realising, while capturing a reset link means that one of them will win and the other will observe their password reset has failed.

Re: But why can't I send people their passwords?

#38

Post by jcampbell1 »

jere wrote: post #5

> 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 y…

In 2007, Gmail had a XSRF vulnerability for setting up filters. It was exploited by attackers that would create a filter 'Contains "password"', 'Forward to: evil@example.com', 'Run on all messages'.

Basically you could visit a malicious webpage, and all emails containing the word "password", would be sent to the attacker.

Re: But why can't I send people their passwords?

#39

Post by thesumofall »

scrollaway wrote: post #26
thesumofall wrote: post #17

For [11]: I think it makes sense to also highlight other approaches than OpenID such as https://passwordless.net which is a sort of way in the middle (disclaimer: I'm the author)

As a huge supporter of Persona, I am intrigued. Can you sell me on how this may be better?

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.

Re: But why can't I send people their passwords?

#40

Post by scrollaway »

pdpi wrote: post #35
scrollaway wrote: post #24

Earlier quoted context omitted.

What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.

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.

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.

Post reply on HN