Live data from Hacker News

Ebay posts every character a user types into the password box

slashcrypto.org

211–220 of 220 posts

Re: Ebay posts every character a user types into the password box

#211
post #62

Earlier quoted context omitted.

> Some front-end dev wasn't sure what's a good timeout to fire the password to the server on, so he or she just put it on keypress. Ebay is not a two bit software startup, it's an eCommerce powerhouse with extensive QA processes.

QA just assures that the deliverable meets the spec. It's perfectly possible to write an excellent implementation of a terrible idea.

or a terrible implementation of a good idea.

Manager: "We need password strength validation." Tech: writes code to send each character of password to server as cleartext Tech: "Done"

Re: Ebay posts every character a user types into the password box

#212

> there are some reasons behind our current solutions but I wouldn’t be able to give you more details on it. I'd be curious to know if anyone here can come up with a good enough reason for sending out the user's email & their password(-prefix) at every keystroke?

They prefer to implement their password strength measurement server side for some reason. Maybe they don't want to make it public by doing it it JavaScript. Or they want to disallow reusing previous passwords, without leaking them to the client.

Or they want to disallow reusing previous passwords, without leaking them to the client.

As an aside, I have always wondered how it is possible to disallow reusing previous passwords if the password is only saved on the server as a salted hash, which is recommended I believe.

Is it possible?

Re: Ebay posts every character a user types into the password box

#213

One that I use regularly that seems to be missing is 'set timer'. Also and amusing request from my father (who uses voice commands far more than I do): 'is there some way to print all of these out?'

I'm guessing you were also reading the post about Google Voice commands before this one, and got confused. https://news.ycombinator.com/item?id=12000264

Re: Ebay posts every character a user types into the password box

#214
post #166

Earlier quoted context omitted.

Avoiding patents of other protocols seems to have been one of the goals, but then Thomas has patented SRP itself. https://www.google.com/patents/US6539479 which is set to expire in two years minus 15 days (Jul 14, 1998).

Wouldn't that be 2 years and /a month/ minus 15 days? :)

You're right.

Re: Ebay posts every character a user types into the password box

#215
post #65

Earlier quoted context omitted.

Is their algorithm so complex that it can't run in a reasonable time using client side javascript? I have trouble thinking of anything that isn't vastly over-engineered and runs slower than the network lag probably is.

I think an overly complex password strength checker is probably dong it wrongly. Besides, when it comes to password complexity you need to tell the end user what the rules are!

Combining a password strength meter with password rules is the sort of thing where most implementations are going to get it wrong. It clutters up the UI a lot, to the point of being too complicated for "average" users to understand.

I prefer seeing one system or the other, but not both.

If you have rules, don't use a password strength meter. Rules are going to be a binary result - "yes the password is good enough", or "no, this password is not acceptable" - which is represented by showing which rule(s) were not respected by the user, or a green checkmark.

A password strength meter can be used when there are no rules enforced, to let the user decide for themselves whether that red progress bar showing a weak password is good enough for their needs. The meter doesn't need to be binary, with red/orange/yellow/green stages. The only reason I don't like password strength meters in general is that there is no standard across sites/services as to what constitutes a strong password. One site will show "password123" as weak, while another will say it's fairly strong. Each implementation has its own arbitrary algorithm that is likely not representative of "true strength".

Re: Ebay posts every character a user types into the password box

#216
post #122

Earlier quoted context omitted.

The reason for using a server-side solution is for a password strength indicator. You need the full algorithm to run against the current entry, and every user-friendly implementation does this on every character input so you know when what you have typed is "strong enough". I'm not particularly a fan of password strength indicators in general, but if you're going to do it at least do it cleanly.

Yes, but why do it on the server and not on the client?

Why do it on the client and not on the server? It's just an implementation decision. I would never bug someone for choosing either one over the other. Most implementations probably have issues with the employed algorithm, best not to waste effort debating the delivery method.

Re: Ebay posts every character a user types into the password box

#217
post #166
post #162

Earlier quoted context omitted.

SRP is an "Augmented PAKE" which does not require the server to ever see the plaintext password. I'm not aware of any others that are claimed to be patent-free.

Avoiding patents of other protocols seems to have been one of the goals, but then Thomas has patented SRP itself. https://www.google.com/patents/US6539479 which is set to expire in two years minus 15 days (Jul 14, 1998).

Ah right. It is patented, but the most common application of SRP can be used for free.

Re: Ebay posts every character a user types into the password box

#218
post #128

Earlier quoted context omitted.

I disagree. Whatever the server receives, it should do all the good things, salted hashing and what-have-you. But no one says what it receives needs to be a plaintext password. Hash on the client side before sending- unsalted, or salt there as well and pass it along to the server- but let's just ensure that the server never has the ability to see a plaintext password. It can't log it, it can't accidentally leak the p…

If you hash, with or without salt, on the client for changing the password, you'll also need to hash identically when checking it (i.e. for login). In effect, the hash becomes the password; even if the plaintext is never leaked the first-level hash is just as good for access.

Yes. I agree. My point is I don't want to ever see plaintext on the server in any form. It won't stop everything, but it's still worth doing.

Re: Ebay posts every character a user types into the password box

#219

Earlier quoted context omitted.

Right, but if a hacker releases a password dump for site X, no one has your password in plaintext, just the log in hash. That said, that solution requires JavaScript.

Yes, but then the attacker can ignore your JavaScript and just send the hash value they got from the dump. If you calculate hash(password) and send that for comparison to the hashed password stored in the user database, then hash(password) is your password from then on.

Yes, but they can't then use the dumped passwords on 300 other websites.

Re: Ebay posts every character a user types into the password box

#220

Earlier quoted context omitted.

Sometimes they stay at exactly the same level forever.

Its a classic quote from Bruce Schneier. I should have attributed it. I thought the crowd would get it.

While often attributed to Schneier, he attributes it to the NSA https://www.schneier.com/blog/archives/2011/08/new_attack_on...
Post reply on HN