21–30 of 220 posts
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?
Earlier quoted context omitted.
But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.
Https is often terminated at a relatively early point, eg the load balancer, so that the request can be properly routed. (Eg if you use AWS, it's generally terminated at ELB). That means the request path may be logged by the load-balancer and whatever routers/proxies they're using, as well as in the request logs of the web server itself. It's completely unnecessary to have everyone's passwords be viewable by however…
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.
> 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?
There is also the possibility of timing attacks on either type of request. By the length you can tell when the HTTPS request is most likely POST /PWDStrength, and from the times that the request is initiated, you can guess at some characteristics of the password (maybe they stopped typing for a second to verify requirements after typing 7 characters; maybe they stopped after 8 because they have to move to the numpad…
It is feasible to reconstruct passwords from timing information alone. This has been done against e.g.
SSH http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf and
TLS https://www.schneier.com/blog/archives/2010/03/side-channel_...
> 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?
Earlier quoted context omitted.
Https is often terminated at a relatively early point, eg the load balancer, so that the request can be properly routed. (Eg if you use AWS, it's generally terminated at ELB). That means the request path may be logged by the load-balancer and whatever routers/proxies they're using, as well as in the request logs of the web server itself. It's completely unnecessary to have everyone's passwords be viewable by however…
Ahhh, understood. There's someone between what you see as "ebay.com", where the GET is decrypted, and the actual ebay machine that will use the password information. I was thinking of it at the user-agent level. The GETs never leave your machine in plain text. I did not consider that the other end where you send the information could be "flakey". Bloody hell, it's a miracle anything works at all.
Earlier quoted context omitted.
Same as every website where you can login.
what do you mean? normally passwords are not stored in logfiles ...
Earlier quoted context omitted.
Same as every website where you can login.
what do you mean? normally passwords are not stored in logfiles ...