Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"... tell them their password is waiting for them in their inbox."

Nope. That email should contain a link to password creation.



I really dislike this sentiment.

97%+ of people don't care about passwords being sent in plain text over email for non-banking sites. Or for accounts that have no info until you populate them.

The other 3% can just log in and CHANGE the password after-the-fact.

I'd rather not inconvenience the majority of my signups, nor force my ideas on how things should work on them.


And what percentage would – like me – delete their account as soon as you send them a plaintext temp password?

You're living in the past if you think this is an acceptable practice. I don't care how trivial your web service is, if you're throwing my password around willy-nilly, I don't want you.


To answer your question, probably less than 1%.

I like the practice of emailing a link to a page where the user can set their password for the first time.


It's unacceptable to transmit in plain-text a password that the user specified.

But if it's a randomly-generated new nonce, seems OK as a pragmatic middle-ground. Folks like us, who care, will log in and change it.


Probably a draw, as you say, since someone could get ahold of an authenticated link in your email, too.


But usually, those links expire, or are only able to be used once. So the password the user creates is secure, and the period the attacker can use the captured link is only from the time the user requests the password reset until the time the user tries to use the reset, it doesn't work, and the user requests another reset.

When a user is sent a password via email, unless that user is required to change eir password upon entering it, it is inherently less secure than sending a link.


This isn't an attack for the downvote. But if you're the type of customer that flips out over getting your temp password in the mail to a blank account, I don't want you. As the troubles are only starting...


Google Apps sends plaintext temporary passwords.


Only if you (admin user) ask it to. Still a bad practice. Also, the premise is that Google trusts itself as an email provider.


Nope. That would require the user to take more action that necessary, since they now have to click on a link and remember your password. It would also be less secure, since they may choose a bad password.


A. They don't need to remember any password. They're creating it for the first time.

B. Minimum password length/complexity. It's not hard to do.

I can't believe you're actually arguing that creating a new password is less secure than using an auto-generated password that was sent via email. I hope you are just confused...


Hell yeah it is less secure. password, letmein, 123456, j@nuary1

All bad passwords. All will be chosen by your users at some point. The last satisfies any complexity requirements I have ever run against in the wild.

There is nothing insecure about sending a plain-text password that compares to a badly chosen password -- email isn't that easy to intercept and properly nobody is hacking your users physical (or wireless) network. At least not compared to the number of people who will be attempting to crack their online password.


"email isn't that easy to intercept and properly nobody is hacking your users physical (or wireless) network".

If you actually believe this, then we will never be in agreement.


For most of your users creating a new password will be much less secure than giving them a password.

> B. Minimum password length/complexity. It's not hard to do.

It is hard to do. That's why so many people reuse passwords, or have hopelessly weak passwords. (Some word with a few vowels swapped for digits, or some word with two digits tacked on the end.)

I agree that sending passwords over email is sub-optimal, but the solution is not to surprise users with a password creation screen.


Are you taking the position that only auto-generated passwords can be secure? I'm trying to understand what conclusion to draw from your comment.

My point was that imposing length validations on passwords is not hard. Complexity validation, while more difficult, is also not exactly a novel problem.

I feel like I'm in bizarro-world with all these people telling me that sending a plaintext password via email is more secure than giving users the option to follow an authenticated link to create their own password because...users can't be trusted to choose good passwords?! Really?


What are the risks for each situation?

Users are hopeless at creating secure passwords. They are especially hopeless at creating secure passwords if you suddenly present them with a password creation screen.

Adding complexity generation does not help. If anything, it makes things worse. People use stupid weak passwords, often re-using them across different websites. They'll do simple substitutions of digits for vowels, or they'll use one word with a couple of digits stuck on the end.

Complexity validation gives a false sense of security.


right, so the email-only signup really just delays the step of creating a password. Is that better?

Would love to see usability commentary on these sites to see if/how they've decided to use one approach over another.


It's better, in that you now at least know who to contact – someone who showed enough interest to provide an email address.


And sending passwords, even temp ones, through plaintext email is just bad practice, a solved problem, and totally unnecessary.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: