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

151–160 of 220 posts

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

#151

Post by maratd »

Pxtl wrote: post #143

For those who didn't read TFA - it does this for the password strength checker when creating a new password, not when logging in. Honestly, I can see the challenge here. A truly robust password strength checker would use dictionaries, making it too heavy to run on the client, and for usability reasons you'd want it to check on keypress. But it would be nice at the very least if they'd send it as POSTs in the body, no…

> But it would be nice at the very least if they'd send it as POSTs in the body, not GET parameters.

If the GET is being sent via XHR over SSL, how is doing a POST any more secure?

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

#152

Post by Pxtl »

jessriedel wrote: post #147
Pxtl wrote: post #143

For those who didn't read TFA - it does this for the password strength checker when creating a new password, not when logging in. Honestly, I can see the challenge here. A truly robust password strength checker would use dictionaries, making it too heavy to run on the client, and for usability reasons you'd want it to check on keypress. But it would be nice at the very least if they'd send it as POSTs in the body, no…

Is a dictionary really that heavy? (Honest question.)

The ones used by security experts are in the GB range.

Obviously you could do more efficient approaches like converting characters to recognize that P@ssw0rd is just Password, but then you've increased the algorithmic complexity you're sending to the client. If you want to get super-fancy, you've got to find word boundaries and whatnot to find that MyP45512345 is really just MyPass12345.

Of course, the simple brute force approach (server-side check if my password in this 5GB db of passwords?) might be too slow to use for this case anyways.

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

#153

Post by edibleEnergy »

vladnyc wrote: post #150
edibleEnergy wrote: post #140

I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.

I signed up also

I'll send you out a registration link shortly.

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

#154

Post by gottam »

hartator wrote: post #116

> Checking the password completely on the server is OK I don't even agree with that, I think the best pratice should be to hash it on the client side before sending it to a server.

How would you even validate the password server-side if you're salting it at the client level?

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

#155

Post by einrealist »

snorremd wrote: post #5

Sending your password as you type it as a GET request query parameter seems awfully hazardous. As you point out the password will appear in all manner of places, such as HTTP server logs. As the username/email is not included an ops person might not directly know from the GET request alone what user the password belongs to. It is not difficult to imagine however that they have enough info to correlate the IP address…

Maybe they plan to cache the responses! I mean, from a POST to a GET, there is clearly a trend.

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

#156

Post by antiffan »

edibleEnergy wrote: post #140

I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.

Really nice work on this. I would have loved this tool on my last big web project.

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

#157

Post by _qbjt »

Dear eBay,

Sending a request on each keyboard event to determine password strength is not only a security vulnerability, it's also poor design. APIs should primarily be used to consume external resources, not stand in for client side functionality.

If providing an API for password strength is important (i.e. you want to guarantee the same behavior across clients), think of your business logic as a resource and not a service. Rather than force the API figure to it out, have the API deliver the criteria for this behavior (regex strings, bounds of password length, etc.) and let your clients figure it out. This addresses the security concern, decouples your client side and server side logic and improves performance across the board by reducing network requests and absolving the server of this responsibility.

If you must go with this design, at least move from a `GET` to `POST` like others are suggesting.

Just my opinion,

Matyi

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

#158

Post by deallocator »

edibleEnergy wrote: post #140

I reproduced it for fun with BugReplay, the site I've been working on for the past year: https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.

Shame it's not mobile optimised, I'd love to check this out right now. Guess I'll have to wait until I get to my laptop

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

#159

Post by xigency »

phs2501 wrote: post #137
mabbo wrote: 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.

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.

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

#160

Post by [deleted] »

cm3 wrote: post #123

Why is it that we didn't improve HTTP Digest Auth but let everyone implement their own mechanism, where the number of those using a challenge response protocol is not worth a mention? Do we have to wait until 2018 before https://tools.ietf.org/id/draft-yusef-httpauth-srp-scheme-00... can be a thing? Not saying SRP is the best option, but compared to what's implemented on websites right now, it is much better. EDIT: I…

[deleted]
Post reply on HN