Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ebay posts every character a user types into the password box

slashcrypto.org

Post reply on HN
Print view View original

81–90 of 220 posts

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

#81

Post by ryanlol »

Artlav wrote: post #37
jgrahamc wrote: post #24

Earlier quoted context omitted.

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

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.

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

#83

Post by pingec »

icebraining wrote: post #47
drodgers wrote: post #40

Earlier quoted context omitted.

"It won't stop a nation state modifying requests in transit and injecting their own js" It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

Pinning doesn't work against the "corporate CA" scenario, at least if the user is using Chrome: Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature t…

Wait, what? So I guess our admin can read my gmail :/

Will pay attention to what certs are being served from now on...

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

#84

Post by tnorthcutt »

developer2 wrote: post #52
arviewer wrote: post #50

Earlier quoted context omitted.

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.

https://github.com/dropbox/zxcvbn

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

#85

Post by chris_wot »

czinck wrote: post #65
developer2 wrote: post #52

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.

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!

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

#86

Post by anentropic »

reitoei wrote: post #62
parandroid wrote: post #36

Earlier quoted context omitted.

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…

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

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

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

#87

Post by Someone1234 »

arviewer wrote: post #49
brown9-2 wrote: post #20

Parameters sent via GET can get cached by proxies and they appear in log-files. Not to argue in favor of sending sensitive data via GET, but I think it is worth pointing out that third-party proxies cannot see the URL or other parts of the HTTP headers or body when the connection is using HTTPS.

But there is a good chance that these GET parameters are logged by the webserver. Even if these servers are very secure and strictly monitored, one bad employee can cause a lot of trouble.

Perhaps, but an employee in that position can steal credentials even without GET logs.

This entire discussion is predicated on a contradictory assumption, that an employee would be corrupt enough to steal credentials from web server logs, but not corrupt enough to steal the same credentials from any other source (inc. database access).

It is like letting a criminal into your home, then being concerned that they might see your security system's pin written on a sticky note on the fridge. Sure, it is a problem, but ultimately the criminal doesn't need that pin to steal your shit, you already let them walk right in.

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

#88

Post by chris_wot »

All those people who think that Amazon don't want anyone to work out their password complexity algorithm... You just generate a script that works out the minimum number of characters and then submit a password list to the strength service. Then you'll know all the strongest passwords according to Amazon, and from here you can hopefully find patterns to construct rules around running dictionary cracks.

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

#89

Post by ncallaway »

czinck wrote: post #75
ncallaway wrote: post #72

Earlier quoted context omitted.

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.

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

#90

Post by sigkill »

developer2 wrote: post #53
splatcollision wrote: post #14

I knew there was a reason I always prefer POSTing data as opposed to GET query params. It still gives attackers the knowledge that if they can get access to the logfiles, they can see passwords. Then the problem becomes getting access to the logfiles! Any leak of relevant information about security is of potential value.

It's less of a concern about an attacker gaining access to the log files, as it is that passwords should simply not be stored plaintext... anywhere . One doesn't really need to ask "why", it's just good common sense.

I might even go as far as saying that passwords should simply not be stored at all anywhere.
Post reply on HN