Hacker News Reader

Comment by wimagguc | Hacker News Reader

> 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?

View on HN

This actually just sounds like a really bad implementation. 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.

And then he included the email too, so the backend could look up the user and make a custom password blacklist for this specific case (eg: no personal details allowed).

I actually don't disagree with doing a POST of a password to check password strength server-side. It might be "cheaper" a bit in some cases.

But sending on every keypress and including the email - that's just silly.

> 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.

I am well aware of that, and agree with you. There had to be some seriously bad decisions made here, and it certainly doesn't look like someone from a big company would make such mistake.

Yet, those kind of bad decisions are made every day, by people all around the world. I wouldn't give benefit of the doubt to anyone these days.

that doesn't mean they don't have bad implementations

Yeah, but being a powerhouse doesn't mean they don't introduce silly bugs. They do. E.g. on Facebook, a year or two ago, you could use dev tools and change hidden input field's value when writing a post and post to anyone's timeline (this story got tons of coverage for a bunch of reasons, vulnerability itself not being the prime one). Does it seem like a silly bug? Definitely. But it happened, it's not the first one, not the last one.

So it's a bit naive to assume devs at popular companies don't make bugs, they are superhumans, etc :)

I've seen some pretty janky pages on eBay.com, and the windows 'Turbolister' software is one of the worst things I've had the displeasure of using.

eBay is sufficiently large, and old-enough, to have substantial tech debt.

I worked at a Fortune 100 that does billions in online sales. You'd be surprised at how often little, improper things like this can just percolate into production. And then they're defended by the people who allowed it to happen.

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"

>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?

I wonder if it ties into their fraud detection systems somehow.

Fraudsters are lazy - so lazy that, for a good long time, you'd see the exact same few recycled photos of counterfeit items being used in item descriptions. No idea if that's changed recently.

Anyway, going back to my main point: I wonder if something about password entry and email address choice serves as an early warning flag.

I'd kinda be surprised, but I could imagine it potentially being useful.

I guess that fraud could be a big part of this, getting every character in sequence says way more about the end user then getting only the password in the end. I wonder how this will affect password manager users though.

That might be it. They might use it to detect if someone is pasting a password in vs typing one in. Which might help identify against bots / attackers stealing someone's ebay account.

Which would explain why Ebay would be secretive. Because the detection is easily mitigated if attackers become aware of the detection.

Same thought here. I was imagining that some sort of timing analysis / fingerprinting could possibly be going on.

But to what end? A valid password is a valid password whether it comes from user that takes 2 minutes to type it in, a password manager, or a bot.

My guess is that they're doing bot detection or something similar using thing like the additional timing information and detection of typing errors.

Both use cases could justify calling an API at every keystroke, where you send out either the user's identifier in the one case (to extract the timing info), or the password(-prefix) in the other (to check for typing errors). Linking together these two is where it becomes especially dangerous.

If this was the case, I would think that a single request where they record the timing between characters clientside and post that timing information along with the password would work better. Timing incoming POST requests as part of a single password reset "session" seems fraught with problems, I can't see how you could really trust the timing numbers you would get. I type my password pretty fast generally and I wouldn't be surprised if the margin of error on that timing is a significant percentage of the average time per key press.

Of course you can't trust anything from the client and both methods are subject to tampering, I'm not sure which is more tamper resistant.

But then what about people who rely on password autofill and password manager ctrl+v users?

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.

You can use a client check to check for the basic requirements, like minimum and maximum length, characters required or allowed etc. Then when the user submits his password, you can do a serverside check.

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.

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.

No, it's more about leaking information to the JS client. If, for example, their password verification rules stipulate that you can't reuse any of your last N passwords, then they would need to make this check server-side as they don't want to provide that information to the client.

Which sending a POST on every keystroke won't really help with anyway, because they can't tell that you typing "h-u-n" will match your old password of "hunter2", assuming it's properly hashed.

Oh, I agree. Every keystroke seems like overkill.

If I were in charge of both requirements and implementation I'd debounce the input by 300-500ms and display a "loading" spinner in the password complexity box until the debounce timer and network request had fully resolved.

I was just trying to explain why, given some business use-cases, doing password validation on the client isn't always possible.

Perhaps their algorithm isn't written in javascript?

Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?

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".

https://github.com/dropbox/zxcvbn

This might get downvoted because it's just a link, but:

zxcvbn is actually a great password strength library, JavaScript, client-side, and only about 400 kB or so last time I checked (compressed, including (!) dictionaries). It was developed by a Dropbox engineer for the password setting/changing dialog at Dropbox, and open sourced, if I'm not mistaken.

Again, this is a great tool, client side, small (smaller than most webpages and adds these days at any rate), and it also allows to provide a list of "custom black list words" not to use in the password (e.g. username, site name, etc.).

AFAIK, zxcvbn really is the gold standard here.

Given this, I don't really see how a server-side check is better or necessary. Ebay really ought to provide a much better answer than "trust us" here.

You can do a lot of server round trips before you reach 400 kB.

Yes, but these 400 kB won't contain any personal data.

What's better: A) compromising security but using less bandwidth, or B) using more bandwidth, but staying secure?

Besides, the password strength js can easily be loaded async.

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.

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?

Building a user's password dictionary?

With common misspellings.

Timing? Perhaps they are timing the typing speed in some way.

Well, that's going to trigger on a large group of people that use password safes.

How common is it to have internet fast enough that a POST request completes between characters? I would expect it's completion in a second or two, enough time for a human to type about 5-15 characters, making the timing information completely meaningless.

This would require that after a second or two the post requests will be instant, and after that second or two they will travel back in time to be delivered simultaneously with all the other requests.

The timing information, despite possibly arriving with a bit of a delay will be just fine. Not only that, but if they really wanted they could just grab the TCP timestamps.

Not a good enough reason, or sane, but what if it's a honeypot of sorts. Perhaps eBay is using the timing information themselves to flag hack attempt sources...

Reply on news.ycombinator.com