User account creation re-imagined [video] | Hacker News Reader

User account creation re-imagined [video]

stefankendall.com

"Unable to display content. Adobe Flash is required."

I had a small chuckle--I hope that's not the future of signup pages.

Here's a description of the video, for those on their phones or flash-impaired devices:

When requiring an account, have only two fields, username and password. Auto-generate both randomly and show them both in plain text. If the user changes the password, save that -- it's their new password. They can enter it on another device. Likewise, if they change the username, save that change.

If they change both username and password to an existing and valid combo, consider that switching users, and I suppose you perform a logout and log in with the new credentials. (This is where it gets a little muddy, in my opinion.)

http://www.imgur.com/njew43E.png

:-(

Thanks for that. I was using screencast.com, and I assumed that it would use HTML5. That's what I get for trusting a service to do the right thing.

I don't understand how this helps the user.

You're assigning a username and password to them. Are they going to take the action to change it to something they will remember? If not, how will they retrieve it when they forget? How is any of this an improvement?

This fails the "don't make me think" test. You're taking something that needs no explanation ( a registration form ) and making its functionality entirely unobvious.

I like this idea. It make s alot of sense in the 'app' world, where one doesn't want to type much, where they just want to 'check it out', and where they don't constantly log in anyway. No email address needed either.

Please, please, PLEASE don't store user's passwords in plaintext on the backend...

That's what I thought too. I guess it wont be hard though to just put asterisks there and store it in md5/sha1. On the other hand allowing the user to change password without knowing the old one it's another security risk, so this is not probably for every app or it needs some work to get done right.

You can only change the password for the current user. If someone gets access to your phone, they can change your password, so this doesn't work for, say, a bank.

If the physical security of the phone is your security, however, this seems like a reasonable level of trust.

There are many apps, like mine, that have non-sensitive data that just needs an account for persistence or extra-app activity.

You could adjust this to require the current password instead of showing it, but in my case that's an unnecessary level of effort. You could still get by with two input fields, I think.

It's not stored in plain-text. Everything is stored hashed and salted with bcrypt, and comparisons happen at the hash level.

The app is stored un-hashed and un-salted in the app, but if someone gets access to your phone, your powerlifting log is the least of your worries.

Reply on news.ycombinator.com