Hacker News new | ask | show | jobs
by msohcw 4608 days ago
Two small icons next to the field, one for autogeneration (a refresh maybe?) and one for password visibility (an eye like IE uses perhaps, a concept common to other software as well.) Keep the generation code in js client side , and send the plaintext to the server via SSL as always. Normal operation of user creation. The plaintext has to be sent at least once over SSL to get hashed on the server side. Hashing on the client side is generally worse because then you'd be more susceptible to MITM attacks. (Actually, either way you'd be more susceptible. Just rely on strong SSL.)
1 comments

Yes re client side generation though it might not be as random, the point is to encourage people to not use the same password. It could be combined with an educational note "Why use this password?" or "Why should I remember a different password? You don't need to..."

Client-side is always MITM friendly without certificate pinning and strong SSL, which is why I have to dial down the paranoia a bit myself: I was just now thinking that you could plant a non-random auto-completed password, but then if you can do that you could just listen for the real password too. (We're assuming you're running JavaScript here after all.)