Bot detection?
Yeah, or copy/paste detection
Ebay posts every character a user types into the password box
31–40 of 220 posts
Re: Ebay posts every character a user types into the password box
#32Parameters 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.
Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.
Re: Ebay posts every character a user types into the password box
#33If someone has broken ebay https they will surely be able to catch the whole password at the end.
As others are saying, using a GET request embeds that password in the URL, which means that server logs on eBay's side will have your password in them. Server logs aren't always the most protected thing in terms of locking down systems and permission management. On the flip side, most server logs do not have POST/PUT data logged.
Ummm... you're assuming that eBay is using a standard web server configured in some default manner. It's far more likely that this is communication with a custom authentication server of some sort. (Where server means a very large collection of machines.)
Re: Ebay posts every character a user types into the password box
#34Parameters 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.
Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.
I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.
Re: Ebay posts every character a user types into the password box
#35> 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?
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.
Re: Ebay posts every character a user types into the password box
#36> 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?
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.
Re: Ebay posts every character a user types into the password box
#37> 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?
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.
Re: Ebay posts every character a user types into the password box
#38> 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.
Re: Ebay posts every character a user types into the password box
#39> 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?
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.
Re: Ebay posts every character a user types into the password box
#40Earlier quoted context omitted.
Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.
I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.
"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.