11 ms·

Ebay posts every character a user types into the password box

497 points by slashcrypto 10y ago

bru 10y ago
> why the website is sending docents of requests to Ebay’s servers. "dozens" maybe?
cocotino 10y ago
Bad title: it works only while you have the password field focused. Bad content: when you log in or register you send your password to the servers anyway. It's irrelevant, since all connections (as shown in your post) are made with https. One could argue "they are seeing what you write even if you haven't sent it yet", but meh, it's just a damn password field, not a chat field. So bad, bad, bad.
- bencollier49 10y ago
  They're embedding the password in a GET request. That'll get logged all over the place.
  - deleted 10y ago
    [deleted]
  - CannisterFlux 10y ago
    But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.
    - SEMW 10y ago
      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 many people have access to one or more of those logs (for a org the size of ebay, maybe 10-100 people?). Sure, it's not as terrible as if it was sent over http, but 'not being as the worst it could possibly be' isn't a very high bar.
      - CannisterFlux 10y ago
        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.
        bencollier49 10y ago
        Not even necessarily, but the https logs are likely archived to another server, and that server will likely be secured completely differently.
      - userbinator 10y ago
        Are you implying that POST data isn't going to be transmitted in cleartext beyond that point? Because that's incorrect - HTTPS doesn't selectively encrypt - the whole connection is encrypted. If you're worried about GET data being sent in cleartext, POST is no different.
        dudus 10y ago
        The point is that GET parameters are more likely to be stored in server logs or other application logs where POST body is usually discarded from such logs. So someone getting access to the logs will have access to a lot of possibly sensitive data, that's all depending on server and application settings, but by default GET are more likely to leave traces than POST. It's a subtle but valid concern.
      - lmm 10y ago
        Maybe ebay do the right thing and terminate on the final endpoint, and keep their logs appropriately secured. We shouldn't assume the worst without knowledge.
    - realusername 10y ago
      It's not so much the HTTPS but the logs, the server logs are not necessary designed to store all the users passwords.
  - deleted 10y ago
    [deleted]
- jfoutz 10y ago
  He's got a point that sending via GET is kinda dirty. I'd hope ebay logs don't log the full url of requests. Sure, getting to those logs would be super difficult, but you really don't want plain text passwords anywhere. In general though, yeah, not that exciting of an article.
- slashcrypto 10y ago
  As I said in the Post, it is not a security vulnerability itself, but I want to point out that it can be very dangerous to put a password in a GET request. And the response of ebay is bad too. But thank you for your constructive comment ;)
  - CannisterFlux 10y ago
    If you're on https ebay, sending GETs to https ebay then the GET parameters are not sent in plain text. The owasp article you link to mentions that GETs can be sent in clear when you have a mixed http/https scenario. I think your screenshots are a little misleading, as not all of the headers and information you show are sent in the clear when using TLS. The response of ebay seems OK, this isn't a big issue at all. EDIT: Sorry for the misunderstanding: as mentioned elsewhere, the problem is not so much the user-agent end, but the hops between where the decryption happens and where the information is used. Why expose the information more than needed there? So I guess ebay's response is a bit lacking. They could make things more secure with relatively little effort.
    - developer2 10y ago
      >> I guess ebay's response is a bit lacking Except that ebay's response was to the POST over https he mentions in the first section of his article. There is absolutely nothing at all suspicious about that. He wasn't looking into a potential security hole there, he was just prodding as to why they do server-side validation in a completely secure manner. His email had nothing to do with security; he was wasting someone's time asking about implementation details. He then went on to find a GET version in another area on the site, for which he makes no mention of having sent an email. This might not be considered a security problem to ebay depending how they manage web server logs, but it's certainly a viable inquiry compared to the POST version he did email about.
venomsnake 10y ago
If someone has broken ebay https they will surely be able to catch the whole password at the end.
- vanwalj 10y ago
  Same as every website where you can login.
  - slashcrypto 10y ago
    what do you mean? normally passwords are not stored in logfiles ...
    - vanwalj 10y ago
      "Normally" ? What refrain you from logging HTTP Body ? It's the same problem as logging HTTP query string. You should consider everything you send over HTTPS public for the receiver in any way.
    - besselheim 10y ago
      The passwords are not necessarily being captured in logfiles, that's a huge assumption. We don't know anything about how eBay stores and manages their web server logs.
- pyre 10y ago
  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.
  - jyounker 10y ago
    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.)
snorremd 10y ago
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 of the password strength request with a user.
- einrealist 10y ago
  Maybe they plan to cache the responses! I mean, from a POST to a GET, there is clearly a trend.
splatcollision 10y ago
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.
- developer2 10y ago
  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.
  - sigkill 10y ago
    I might even go as far as saying that passwords should simply not be stored at all anywhere.
- developer2 10y ago
  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.
0942v8653 10y ago
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 on their keyboard). edit: the best sopution for this is probably to wait a specified amount between requests, rather than doing it with each character.
- willvarfar 10y ago
  Came here to say this. 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 http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf and TLS https://www.schneier.com/blog/archives/2010/03/side-channel_at.html https://www.schneier.com/blog/archives/2010/03/side-channel_...
  - ryanlol 10y ago
    That's a very interesting interpretation of the linked papers. While timing information may make brute force attacks against the passwords easier, it is not feasible to reconstruct passwords based on the timing information exposed by Ebay. It is also worth noting that the ability to perform more efficient brute force searches doesn't really matter in the case of Ebay, as it will not make such attacks feasible over the internet.
    - willvarfar 10y ago
      Attacks only get better.
      - tfinniga 10y ago
        Sometimes they stay at exactly the same level forever.
brown9-2 10y ago
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.
- slashcrypto 10y ago
  you got a point, i will do a short edit here.
- mschuster91 10y ago
  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.
  - cmdrfred 10y ago
    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.
    - drodgers 10y ago
      "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.
      - deleted 10y ago
        [deleted]
      - icebraining 10y ago
        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 to defeat the protections of key pinning. https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq...
wimagguc 10y ago
> 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?
- jgrahamc 10y ago
  Timing? Perhaps they are timing the typing speed in some way.
  - lsaferite 10y ago
    Well, that's going to trigger on a large group of people that use password safes.
  - Artlav 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - ryanlol 10y ago
      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.
- rkangel 10y ago
  My guess is that they're doing bot detection or something similar using thing like the additional timing information and detection of typing errors.
fh973 10y ago
Bot detection?
- spydum 10y ago
  Yeah, or copy/paste detection
- allworknoplay 10y ago
  Neither bot nor copy/paste detection require this. If you're checking keystroke pace/timing you could simply send a keystroke or clipboard event without the actual contents. Also, like, if they're sophisticated enough to be doing that, they should probably get the basics right.
deleted 10y ago
[deleted]
ivanhoe 10y ago
how do you know that they didn't disable logs for this url?
- lstamour 10y ago
  Because (a) it's very unlikely given the use of POST elsewhere that they even realised this was using GET, and (b) other services can log URLs, such as your browser's history. By default, it may not matter, but perhaps of extensions get involved... It's true, this isn't a straightforward vulnerability but it doesn't seem to be well-considered given the inconsistent use of both GET and POST for the same terrifying call.
- cwilkes 10y ago
  It is far safer not to do it in the first place. I can easily see a new sys admin coming in and wondering where all the logs are for a url and enabling it. Or they send their logs to an analytics firm. The firm says innocently enough "it doesn't look like we are getting all the logs" and then it is turned on. There's a lot of ways a policy can be circumvented just because people were trying to do their jobs and didn't know better. Also it is highly unlikely that they have another process to confirm that they aren't logging that url
- kstrauser 10y ago
  How do you know that they did? It's up to eBay to state that they changed to a non-default setup, not on us to assume so without asking.
iask 10y ago
After reading the public post and these comments, do you think they (eBay) will give a better explanation...or better, an explanation...as to why they do this? Passwords are becoming difficult to maintain, even with a password manager. They should've, at least, obfuscate it in some way.
HannibalLecter 10y ago
Well it's obvious that someone working at Ebay is collecting these passwords. Either they intend to steal a lot of money, or they intend to create user profiles based on data that would otherwise be encrypted to them, or they could also be trying to break the account encryption on the whole network this way. Collect enough valid passwords and use them to get enough to make a fingerprint that could enable them to read passwords without having access to higher security clearance.
deleted 10y ago
[deleted]
wyldfire 10y ago
> This is not a security vulnerability itself because I think they have implemented this for some reason IMO just because the behavior is by design doesn't mean it's not a vulnerability. That said, this one seems like a grey area. I'd be worried about password information leaking by making TLS attacks easier in this mode.
- ryanlol 10y ago
  This only affects a specific form that the user might interact with once a year (and that's being really optimistic), I don't really see it generating enough requests to make TLS attacks easier.
  - thinkt4nk 10y ago
    If it increases the attack surface at all, it makes it easier. Being that this site facilitates monetary transactions, I would hope they would be trying to limit their attack surface in any way possible. I think the real point here is that there are more secure solutions. Saying that it's not all that less secure isn't a great argument.
    - ryanlol 10y ago
      >I think the real point here is that there are more secure solutions. Saying that it's not all that less secure isn't a great argument. I'd say it's a very good argument, this appears to be a non-issue that doesn't justify the dev time spent on "fixing" it. We don't live in a world with infinite dev resources. Edit: Since someone appears to disagree, how would you exploit this "bug"?
deleted 10y ago
[deleted]
chris_wot 10y ago
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.
jfahrenkrug 10y ago
"Let us help you make your password more secure by sending it over the wire a gazillion times."
zobby 10y ago
they are actually right to do this as countermeasure to: - Phishing - login/brute bots
Pxtl 10y ago
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, not GET parameters.
- jessriedel 10y ago
  Is a dictionary really that heavy? (Honest question.)
  - RussianCow 10y ago
    Depends on how big the dictionary is. :)
  - Pxtl 10y ago
    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.
    - colejohnson66 10y ago
      > The ones used by security experts are in the GB range. Citation? The only multi gigabyte "dictionaries" I've seen are rainbow tables. I'm genuinely curious why you'd need multiple gigabytes when the Dictionary.com app a few years ago was no more than 200 megabytes.
  - FabHK 10y ago
    The (most excellent) zxcvbn password strength checking library [1] (developed by an engineer at Dropbox) is 400 kB (compressed) including dictionaries. [1] https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
esnard 10y ago
Twitter also sends the password + email + name on each keypress once the user has entered at least 6 characters on it signup page. [0] [0]: https://twitter.com/signup
- sonnyz 10y ago
  Ugh, I had to do this once on the sign up page at a small company I worked for about 10 years ago. Ever since then, I've been weary about beginning to fill out any forms unless I really, really want them to have the info. I still think its messed up to store user data that hasn't been submitted.
  - Nagyman 10y ago
    Yeah, there are shady techniques from companies offering cart abandonment solutions that do exactly that (e.g. VEInteractive). If you type in an email address and don't submit the form, they'll still send you chaser emails. I think there are valid reasons to store incomplete form data, but I don't think it should be used for reasons the customer did not intend (e.g. receiving emails).
- kyrra 10y ago
  This one is interesting. Looks like they don't send any requests for username. For email address, they have a delay before sending to the server to see if it's a used email address (if you type quickly enough, it will only send a single request to validate the email). For password, they start sending every character you type once the field has 6 characters in it. It then sends your full form details on every keypress (plus it has a delayed send to the same password_strength call, similar to what they do for emails). So if you type your password slowly, it will send your details twice for every keypress.
foobar20202 10y ago
As an attacker this gives me information about how many characters are in password. Which can be quite useful information.
emeraldd 10y ago
Today's xkcd is surprisingly relevant: http://m.xkcd.com/1700/ http://m.xkcd.com/1700/
- tempodox 10y ago
  Indeed. Who would use that site any more after this “feature” has been publicized?
  - raldi 10y ago
    About 162 million people.
    - xufi 10y ago
      Ouch, that's quite a bit indeed. One reason why I shop at Amazon more often.
      - raldi 10y ago
        https://en.wikipedia.org/wiki/Dancing_pigs#Origins https://en.wikipedia.org/wiki/Dancing_pigs#Origins
athenot 10y ago
I hope they pad the requests with some random data, otherwise they are sending encrypted requests with very little entropy.
l3m0ndr0p 10y ago
Maybe it's a way of allowing the Law enforcement or 3 letter agency to decipher a password a little easier. Break out every keystroke, even if it's encrypted vs the entire encrypted password.
hartator 10y ago
> 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.
- mikeash 10y ago
  I'd agree if the client in some way exists independently of the server. For example, if you have a smartphone app, then client-side hashing could be useful. But for a web page, what's the point? The server is in full control of the JavaScript they send you. If the server is compromised, it can easily bypass the client-side hashing by sending your browser different code.
- zip1234 10y ago
  Hashing it on the client side doesn't really have any positive effect on security as the client must then know what salt is used for the hash. This is less secure than just hashing on the server as the salt and number of hash iterations is then unknown by the client (or potential attackers).
  - mabbo 10y ago
    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 plaintext. Will that solve all problems? Oh, hell no. But it at least strengthens the mitigation against certain attacks or mistakes.
    - phs2501 10y ago
      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.
cm3 10y ago
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.html 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 probably am missing details, but surely some secure challenge response protocol must be available for broad implementation in browsers without concern for patents, right?
- deleted 10y ago
  [deleted]
- lann 10y ago
  SRP is an "Augmented PAKE" which does not require the server to ever see the plaintext password. I'm not aware of any others that are claimed to be patent-free.
  - cm3 10y ago
    Avoiding patents of other protocols seems to have been one of the goals, but then Thomas has patented SRP itself. https://www.google.com/patents/US6539479 https://www.google.com/patents/US6539479 which is set to expire in two years minus 15 days (Jul 14, 1998).
    - colejohnson66 10y ago
      Wouldn't that be 2 years and /a month/ minus 15 days? :)
      - cm3 10y ago
        You're right.
    - cm3 10y ago
      2 or maybe 4 years would be reasonable to earn back (some or all of) the investment, and allow others to improve upon and maybe even patent the new invention. As it stands, whole industries are held back due to 20 years for patents.
tempVariable 10y ago
I did some penetration testing on the Snapshat application last year. It was also very chatty every key-press on the craete/login screens.
olantonan 10y ago
> The main point I think is, that GET Requests are logged in log-files which are usually accessible by more people that the main database. This is an outright assumption, and it's a bad one. This is a non-issue, because they do NOT log these requests, and it's https. So move on, this is just noise.
- stenius 10y ago
  A lot of setups have one machine doing the SSL and then forwarding the requests over HTTP to backend servers which are logging the requests and would include GET parameters in the log file.
- hughw 10y ago
  I don't know where you got the information that they do not log these requests, but it is a good assumption, not a bad one. It would be atypical not to log every https request.
chflags 10y ago
So it's not possible to log on without enabling Javascript? I guess that's one way to coerce the user into enabling Javascript, at least temporarily.
- Pxtl 10y ago
  This is the change-password form, not the login form.
edibleEnergy 10y ago
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-aa0f-8f5503d9c663 https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.
- leesalminen 10y ago
  Very cool app! I've signed up for the beta; this could be a game changer for my support team.
  - edibleEnergy 10y ago
    Thanks! I got the notification, I'll send you over a registration invite, would love to get your feedback.
- vladnyc 10y ago
  I signed up also
  - edibleEnergy 10y ago
    I'll send you out a registration link shortly.
- antiffan 10y ago
  Really nice work on this. I would have loved this tool on my last big web project.
- deallocator 10y ago
  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
  - edibleEnergy 10y ago
    Yeah we've put in some work to make it usable on mobile, but I wouldn't call it optimized for mobile yet.
supernintendo 10y ago
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
- ad-hominem 10y ago
  Thanks, super nintendo chalmers! - ebay security team
- gohrt 10y ago
  This is a terrible idea. It would allow a client to ignore the requirements, and submit an invalid password.
  - supernintendo 10y ago
    You have heard of server-side validation, right?
chrisxcross 10y ago
Google does the same. They regularly send your password to their server to rate it. A curl-example is provided below. I think I already noticed that some websites used googles api to do the rating of passwords on their website but I can't recall where I saw it. curl 'https://accounts.google.com/RatePassword' https://accounts.google.com/RatePassword' -H 'Content-Type: application/x-www-form-urlencoded' --data 'Passwd=jbcfaihrwefgbGWETZHGAESjbnajfcw24704%$§&%§!vf&Emailnotme@useless.domain=&FirstName=Hacker&LastName=News' or another endpoint: curl 'https://accounts.google.com/InputValidator?resource=SignUp' https://accounts.google.com/InputValidator?resource=SignUp' -H 'Content-Type: application/json' -d '{"input01":{"Input":"Passwd","Passwd":"GoogleBatteryHorseStaple","PasswdAgain":"GoogleBatteryHorseStaple","FirstName":"Hacker","LastName":"News","GmailAddress":"i-have@none.yet"},"Locale":"en"}'
- gohrt 10y ago
  "Sending your password to the server" -- obviously required, that's what passwords are for. "Sending each character of your password to the server, before you explicitly agree to submit" is quite another.
godgod 10y ago
Facebook does the same. Whatever you type into any input boxes on their website is captured even if you don't hit the send button.
marme 10y ago
They almost certainly do this to detect bots trying to change passwords. If the bot tries to change passwords for hundreds of accounts at once they will end up sending thousands of requests to the password checker and be ip banned and it can silently just reject every password they try to submit to not tip off the attacker that they have been detected. It is a terrible way to implement bot detection but with ebay owning paypal they are on the hook for lost revenue so bot detection probably takes higher priority than other security due to the actual economic impact of bots who steal hundreds or thousands of account at a time being so bad for them
JamesUtah07 10y ago
It'd be nice if they additionally implemented https everywhere while they're at it
simbalion 10y ago
I wonder if there is any example of a large corporation taking action after a flaw is submitted via an online email form? I think those forms are sent to people who's job it is to disregard their content as much as possible.
deleted 10y ago
[deleted]
entelechy0 10y ago
Google Chrome does this also.
hyperion2010 10y ago
One that I use regularly that seems to be missing is 'set <N> <hour/minute> timer'. Also and amusing request from my father (who uses voice commands far more than I do): 'is there some way to print all of these out?'
- brokenmachine 10y ago
  I'm guessing you were also reading the post about Google Voice commands before this one, and got confused. https://news.ycombinator.com/item?id=12000264 https://news.ycombinator.com/item?id=12000264
mdpm 10y ago
How has no-one here made the observation that the reason for this is due to true password strength checks, that use existing password distribution data that is prohibitive in size to send to the browser? They're not doing the wrong thing, and the risk of side-channel attacks on this infrequent behaviour (i.e., not authentication) are trivial compared to the risks of high entropy passwords that are also highly reused, and are thus vulnerable to trivial brute force attempts.
paulddraper 10y ago
The HN title seems odd. Most websites send all the characters (unless I suppose backspace is used).

497 points by slashcrypto 10y ago

bru 10y ago

> why the website is sending docents of requests to Ebay’s servers. "dozens" maybe?

Bad title: it works only while you have the password field focused. Bad content: when you log in or register you send your password to the servers anyway. It's irrelevant, since all connections (as shown in your post) are made with https. One could argue "they are seeing what you write even if you haven't sent it yet", but meh, it's just a damn password field, not a chat field. So bad, bad, bad.

bencollier49 10y ago
They're embedding the password in a GET request. That'll get logged all over the place.
- deleted 10y ago
  [deleted]
- CannisterFlux 10y ago
  But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.
  - SEMW 10y ago
    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 many people have access to one or more of those logs (for a org the size of ebay, maybe 10-100 people?). Sure, it's not as terrible as if it was sent over http, but 'not being as the worst it could possibly be' isn't a very high bar.
    - CannisterFlux 10y ago
      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.
      - bencollier49 10y ago
        Not even necessarily, but the https logs are likely archived to another server, and that server will likely be secured completely differently.
    - userbinator 10y ago
      Are you implying that POST data isn't going to be transmitted in cleartext beyond that point? Because that's incorrect - HTTPS doesn't selectively encrypt - the whole connection is encrypted. If you're worried about GET data being sent in cleartext, POST is no different.
      - dudus 10y ago
        The point is that GET parameters are more likely to be stored in server logs or other application logs where POST body is usually discarded from such logs. So someone getting access to the logs will have access to a lot of possibly sensitive data, that's all depending on server and application settings, but by default GET are more likely to leave traces than POST. It's a subtle but valid concern.
    - lmm 10y ago
      Maybe ebay do the right thing and terminate on the final endpoint, and keep their logs appropriately secured. We shouldn't assume the worst without knowledge.
  - realusername 10y ago
    It's not so much the HTTPS but the logs, the server logs are not necessary designed to store all the users passwords.
- deleted 10y ago
  [deleted]
jfoutz 10y ago
He's got a point that sending via GET is kinda dirty. I'd hope ebay logs don't log the full url of requests. Sure, getting to those logs would be super difficult, but you really don't want plain text passwords anywhere. In general though, yeah, not that exciting of an article.
slashcrypto 10y ago
As I said in the Post, it is not a security vulnerability itself, but I want to point out that it can be very dangerous to put a password in a GET request. And the response of ebay is bad too. But thank you for your constructive comment ;)
- CannisterFlux 10y ago
  If you're on https ebay, sending GETs to https ebay then the GET parameters are not sent in plain text. The owasp article you link to mentions that GETs can be sent in clear when you have a mixed http/https scenario. I think your screenshots are a little misleading, as not all of the headers and information you show are sent in the clear when using TLS. The response of ebay seems OK, this isn't a big issue at all. EDIT: Sorry for the misunderstanding: as mentioned elsewhere, the problem is not so much the user-agent end, but the hops between where the decryption happens and where the information is used. Why expose the information more than needed there? So I guess ebay's response is a bit lacking. They could make things more secure with relatively little effort.
  - developer2 10y ago
    >> I guess ebay's response is a bit lacking Except that ebay's response was to the POST over https he mentions in the first section of his article. There is absolutely nothing at all suspicious about that. He wasn't looking into a potential security hole there, he was just prodding as to why they do server-side validation in a completely secure manner. His email had nothing to do with security; he was wasting someone's time asking about implementation details. He then went on to find a GET version in another area on the site, for which he makes no mention of having sent an email. This might not be considered a security problem to ebay depending how they manage web server logs, but it's certainly a viable inquiry compared to the POST version he did email about.

venomsnake 10y ago

If someone has broken ebay https they will surely be able to catch the whole password at the end.

vanwalj 10y ago
Same as every website where you can login.
- slashcrypto 10y ago
  what do you mean? normally passwords are not stored in logfiles ...
  - vanwalj 10y ago
    "Normally" ? What refrain you from logging HTTP Body ? It's the same problem as logging HTTP query string. You should consider everything you send over HTTPS public for the receiver in any way.
  - besselheim 10y ago
    The passwords are not necessarily being captured in logfiles, that's a huge assumption. We don't know anything about how eBay stores and manages their web server logs.
pyre 10y ago
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.
- jyounker 10y ago
  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.)

snorremd 10y ago

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 of the password strength request with a user.

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

splatcollision 10y ago

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.

developer2 10y ago
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.
- sigkill 10y ago
  I might even go as far as saying that passwords should simply not be stored at all anywhere.
developer2 10y ago
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.

0942v8653 10y ago

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 on their keyboard). edit: the best sopution for this is probably to wait a specified amount between requests, rather than doing it with each character.

willvarfar 10y ago
Came here to say this. 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 http://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf and TLS https://www.schneier.com/blog/archives/2010/03/side-channel_at.html https://www.schneier.com/blog/archives/2010/03/side-channel_...
- ryanlol 10y ago
  That's a very interesting interpretation of the linked papers. While timing information may make brute force attacks against the passwords easier, it is not feasible to reconstruct passwords based on the timing information exposed by Ebay. It is also worth noting that the ability to perform more efficient brute force searches doesn't really matter in the case of Ebay, as it will not make such attacks feasible over the internet.
  - willvarfar 10y ago
    Attacks only get better.
    - tfinniga 10y ago
      Sometimes they stay at exactly the same level forever.

brown9-2 10y ago

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.

slashcrypto 10y ago
you got a point, i will do a short edit here.
mschuster91 10y ago
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.
- cmdrfred 10y ago
  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.
  - drodgers 10y ago
    "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.
    - deleted 10y ago
      [deleted]
    - icebraining 10y ago
      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 to defeat the protections of key pinning. https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq...

wimagguc 10y ago

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

jgrahamc 10y ago
Timing? Perhaps they are timing the typing speed in some way.
- lsaferite 10y ago
  Well, that's going to trigger on a large group of people that use password safes.
- Artlav 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - ryanlol 10y ago
    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.
rkangel 10y ago
My guess is that they're doing bot detection or something similar using thing like the additional timing information and detection of typing errors.

fh973 10y ago

Bot detection?

spydum 10y ago
Yeah, or copy/paste detection
allworknoplay 10y ago
Neither bot nor copy/paste detection require this. If you're checking keystroke pace/timing you could simply send a keystroke or clipboard event without the actual contents. Also, like, if they're sophisticated enough to be doing that, they should probably get the basics right.

deleted 10y ago

[deleted]

ivanhoe 10y ago

how do you know that they didn't disable logs for this url?

lstamour 10y ago
Because (a) it's very unlikely given the use of POST elsewhere that they even realised this was using GET, and (b) other services can log URLs, such as your browser's history. By default, it may not matter, but perhaps of extensions get involved... It's true, this isn't a straightforward vulnerability but it doesn't seem to be well-considered given the inconsistent use of both GET and POST for the same terrifying call.
cwilkes 10y ago
It is far safer not to do it in the first place. I can easily see a new sys admin coming in and wondering where all the logs are for a url and enabling it. Or they send their logs to an analytics firm. The firm says innocently enough "it doesn't look like we are getting all the logs" and then it is turned on. There's a lot of ways a policy can be circumvented just because people were trying to do their jobs and didn't know better. Also it is highly unlikely that they have another process to confirm that they aren't logging that url
kstrauser 10y ago
How do you know that they did? It's up to eBay to state that they changed to a non-default setup, not on us to assume so without asking.

iask 10y ago

After reading the public post and these comments, do you think they (eBay) will give a better explanation...or better, an explanation...as to why they do this? Passwords are becoming difficult to maintain, even with a password manager. They should've, at least, obfuscate it in some way.

HannibalLecter 10y ago

Well it's obvious that someone working at Ebay is collecting these passwords. Either they intend to steal a lot of money, or they intend to create user profiles based on data that would otherwise be encrypted to them, or they could also be trying to break the account encryption on the whole network this way. Collect enough valid passwords and use them to get enough to make a fingerprint that could enable them to read passwords without having access to higher security clearance.

deleted 10y ago

[deleted]

wyldfire 10y ago

> This is not a security vulnerability itself because I think they have implemented this for some reason IMO just because the behavior is by design doesn't mean it's not a vulnerability. That said, this one seems like a grey area. I'd be worried about password information leaking by making TLS attacks easier in this mode.

ryanlol 10y ago
This only affects a specific form that the user might interact with once a year (and that's being really optimistic), I don't really see it generating enough requests to make TLS attacks easier.
- thinkt4nk 10y ago
  If it increases the attack surface at all, it makes it easier. Being that this site facilitates monetary transactions, I would hope they would be trying to limit their attack surface in any way possible. I think the real point here is that there are more secure solutions. Saying that it's not all that less secure isn't a great argument.
  - ryanlol 10y ago
    >I think the real point here is that there are more secure solutions. Saying that it's not all that less secure isn't a great argument. I'd say it's a very good argument, this appears to be a non-issue that doesn't justify the dev time spent on "fixing" it. We don't live in a world with infinite dev resources. Edit: Since someone appears to disagree, how would you exploit this "bug"?

deleted 10y ago

[deleted]

chris_wot 10y ago

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.

jfahrenkrug 10y ago

"Let us help you make your password more secure by sending it over the wire a gazillion times."

zobby 10y ago

they are actually right to do this as countermeasure to: - Phishing - login/brute bots

Pxtl 10y ago

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, not GET parameters.

jessriedel 10y ago
Is a dictionary really that heavy? (Honest question.)
- RussianCow 10y ago
  Depends on how big the dictionary is. :)
- Pxtl 10y ago
  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.
  - colejohnson66 10y ago
    > The ones used by security experts are in the GB range. Citation? The only multi gigabyte "dictionaries" I've seen are rainbow tables. I'm genuinely curious why you'd need multiple gigabytes when the Dictionary.com app a few years ago was no more than 200 megabytes.
- FabHK 10y ago
  The (most excellent) zxcvbn password strength checking library [1] (developed by an engineer at Dropbox) is 400 kB (compressed) including dictionaries. [1] https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn

esnard 10y ago

Twitter also sends the password + email + name on each keypress once the user has entered at least 6 characters on it signup page. [0] [0]: https://twitter.com/signup

sonnyz 10y ago
Ugh, I had to do this once on the sign up page at a small company I worked for about 10 years ago. Ever since then, I've been weary about beginning to fill out any forms unless I really, really want them to have the info. I still think its messed up to store user data that hasn't been submitted.
- Nagyman 10y ago
  Yeah, there are shady techniques from companies offering cart abandonment solutions that do exactly that (e.g. VEInteractive). If you type in an email address and don't submit the form, they'll still send you chaser emails. I think there are valid reasons to store incomplete form data, but I don't think it should be used for reasons the customer did not intend (e.g. receiving emails).
kyrra 10y ago
This one is interesting. Looks like they don't send any requests for username. For email address, they have a delay before sending to the server to see if it's a used email address (if you type quickly enough, it will only send a single request to validate the email). For password, they start sending every character you type once the field has 6 characters in it. It then sends your full form details on every keypress (plus it has a delayed send to the same password_strength call, similar to what they do for emails). So if you type your password slowly, it will send your details twice for every keypress.

foobar20202 10y ago

As an attacker this gives me information about how many characters are in password. Which can be quite useful information.

emeraldd 10y ago

Today's xkcd is surprisingly relevant: http://m.xkcd.com/1700/ http://m.xkcd.com/1700/

tempodox 10y ago
Indeed. Who would use that site any more after this “feature” has been publicized?
- raldi 10y ago
  About 162 million people.
  - xufi 10y ago
    Ouch, that's quite a bit indeed. One reason why I shop at Amazon more often.
    - raldi 10y ago
      https://en.wikipedia.org/wiki/Dancing_pigs#Origins https://en.wikipedia.org/wiki/Dancing_pigs#Origins

athenot 10y ago

I hope they pad the requests with some random data, otherwise they are sending encrypted requests with very little entropy.

l3m0ndr0p 10y ago

Maybe it's a way of allowing the Law enforcement or 3 letter agency to decipher a password a little easier. Break out every keystroke, even if it's encrypted vs the entire encrypted password.

hartator 10y ago

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

mikeash 10y ago
I'd agree if the client in some way exists independently of the server. For example, if you have a smartphone app, then client-side hashing could be useful. But for a web page, what's the point? The server is in full control of the JavaScript they send you. If the server is compromised, it can easily bypass the client-side hashing by sending your browser different code.
zip1234 10y ago
Hashing it on the client side doesn't really have any positive effect on security as the client must then know what salt is used for the hash. This is less secure than just hashing on the server as the salt and number of hash iterations is then unknown by the client (or potential attackers).
- mabbo 10y ago
  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 plaintext. Will that solve all problems? Oh, hell no. But it at least strengthens the mitigation against certain attacks or mistakes.
  - phs2501 10y ago
    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.

cm3 10y ago

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.html 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 probably am missing details, but surely some secure challenge response protocol must be available for broad implementation in browsers without concern for patents, right?

deleted 10y ago
[deleted]
lann 10y ago
SRP is an "Augmented PAKE" which does not require the server to ever see the plaintext password. I'm not aware of any others that are claimed to be patent-free.
- cm3 10y ago
  Avoiding patents of other protocols seems to have been one of the goals, but then Thomas has patented SRP itself. https://www.google.com/patents/US6539479 https://www.google.com/patents/US6539479 which is set to expire in two years minus 15 days (Jul 14, 1998).
  - colejohnson66 10y ago
    Wouldn't that be 2 years and /a month/ minus 15 days? :)
    - cm3 10y ago
      You're right.
  - cm3 10y ago
    2 or maybe 4 years would be reasonable to earn back (some or all of) the investment, and allow others to improve upon and maybe even patent the new invention. As it stands, whole industries are held back due to 20 years for patents.

tempVariable 10y ago

I did some penetration testing on the Snapshat application last year. It was also very chatty every key-press on the craete/login screens.

olantonan 10y ago

> The main point I think is, that GET Requests are logged in log-files which are usually accessible by more people that the main database. This is an outright assumption, and it's a bad one. This is a non-issue, because they do NOT log these requests, and it's https. So move on, this is just noise.

stenius 10y ago
A lot of setups have one machine doing the SSL and then forwarding the requests over HTTP to backend servers which are logging the requests and would include GET parameters in the log file.
hughw 10y ago
I don't know where you got the information that they do not log these requests, but it is a good assumption, not a bad one. It would be atypical not to log every https request.

chflags 10y ago

So it's not possible to log on without enabling Javascript? I guess that's one way to coerce the user into enabling Javascript, at least temporarily.

Pxtl 10y ago
This is the change-password form, not the login form.

edibleEnergy 10y ago

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-aa0f-8f5503d9c663 https://app.bugreplay.com/shared/report/3efa632d-5b51-45f1-a... Checks out, password is in the GET param.

leesalminen 10y ago
Very cool app! I've signed up for the beta; this could be a game changer for my support team.
- edibleEnergy 10y ago
  Thanks! I got the notification, I'll send you over a registration invite, would love to get your feedback.
vladnyc 10y ago
I signed up also
- edibleEnergy 10y ago
  I'll send you out a registration link shortly.
antiffan 10y ago
Really nice work on this. I would have loved this tool on my last big web project.
deallocator 10y ago
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
- edibleEnergy 10y ago
  Yeah we've put in some work to make it usable on mobile, but I wouldn't call it optimized for mobile yet.

supernintendo 10y ago

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

ad-hominem 10y ago
Thanks, super nintendo chalmers! - ebay security team
gohrt 10y ago
This is a terrible idea. It would allow a client to ignore the requirements, and submit an invalid password.
- supernintendo 10y ago
  You have heard of server-side validation, right?

chrisxcross 10y ago

Google does the same. They regularly send your password to their server to rate it. A curl-example is provided below. I think I already noticed that some websites used googles api to do the rating of passwords on their website but I can't recall where I saw it. curl 'https://accounts.google.com/RatePassword' https://accounts.google.com/RatePassword' -H 'Content-Type: application/x-www-form-urlencoded' --data 'Passwd=jbcfaihrwefgbGWETZHGAESjbnajfcw24704%$§&%§!vf&Emailnotme@useless.domain=&FirstName=Hacker&LastName=News' or another endpoint: curl 'https://accounts.google.com/InputValidator?resource=SignUp' https://accounts.google.com/InputValidator?resource=SignUp' -H 'Content-Type: application/json' -d '{"input01":{"Input":"Passwd","Passwd":"GoogleBatteryHorseStaple","PasswdAgain":"GoogleBatteryHorseStaple","FirstName":"Hacker","LastName":"News","GmailAddress":"i-have@none.yet"},"Locale":"en"}'

gohrt 10y ago
"Sending your password to the server" -- obviously required, that's what passwords are for. "Sending each character of your password to the server, before you explicitly agree to submit" is quite another.

godgod 10y ago

Facebook does the same. Whatever you type into any input boxes on their website is captured even if you don't hit the send button.

marme 10y ago

They almost certainly do this to detect bots trying to change passwords. If the bot tries to change passwords for hundreds of accounts at once they will end up sending thousands of requests to the password checker and be ip banned and it can silently just reject every password they try to submit to not tip off the attacker that they have been detected. It is a terrible way to implement bot detection but with ebay owning paypal they are on the hook for lost revenue so bot detection probably takes higher priority than other security due to the actual economic impact of bots who steal hundreds or thousands of account at a time being so bad for them

JamesUtah07 10y ago

It'd be nice if they additionally implemented https everywhere while they're at it

simbalion 10y ago

I wonder if there is any example of a large corporation taking action after a flaw is submitted via an online email form? I think those forms are sent to people who's job it is to disregard their content as much as possible.

deleted 10y ago

[deleted]

entelechy0 10y ago

Google Chrome does this also.

hyperion2010 10y ago

One that I use regularly that seems to be missing is 'set <N> <hour/minute> timer'. Also and amusing request from my father (who uses voice commands far more than I do): 'is there some way to print all of these out?'

brokenmachine 10y ago
I'm guessing you were also reading the post about Google Voice commands before this one, and got confused. https://news.ycombinator.com/item?id=12000264 https://news.ycombinator.com/item?id=12000264

mdpm 10y ago

How has no-one here made the observation that the reason for this is due to true password strength checks, that use existing password distribution data that is prohibitive in size to send to the browser? They're not doing the wrong thing, and the risk of side-channel attacks on this infrequent behaviour (i.e., not authentication) are trivial compared to the risks of high entropy passwords that are also highly reused, and are thus vulnerable to trivial brute force attempts.

paulddraper 10y ago

The HN title seems odd. Most websites send all the characters (unless I suppose backspace is used).