Ebay posts every character a user types into the password box
slashcrypto.org
slashcrypto.org
edit: the best sopution for this is probably to wait a specified amount between requests, rather than doing it with each character.
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_...
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.
There simply isn't enough data.
Luckily, not my kind of a gig.
>http://www.wired.com/2011/10/iphone-keylogger-spying/ etc.
This attack depends on being able to identify individual keys so it's not really applicable here. However, a similar attack might be possible here if not for the very small sample size.
This is probably secure, but non standard password exchanges open up a lot of possibility's.
One small idea: Once the network traffic starts flowing, it's difficult to switch to the Javascript tab because it's constantly flowing off the screen. Maybe make the tabs fixed in place? Or have a check mark that can make them fixed or unfixed?
I expected network requests to occur in the Network Traffic window, however no requests ever showed up.
Can I make a BugReplay of this BugReplay?
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
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?
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.
Ebay is not a two bit software startup, it's an eCommerce powerhouse with extensive QA processes.
Yet, those kind of bad decisions are made every day, by people all around the world. I wouldn't give benefit of the doubt to anyone these days.
So it's a bit naive to assume devs at popular companies don't make bugs, they are superhumans, etc :)
eBay is sufficiently large, and old-enough, to have substantial tech debt.
Manager: "We need password strength validation." Tech: writes code to send each character of password to server as cleartext Tech: "Done"
I wonder if it ties into their fraud detection systems somehow.
Fraudsters are lazy - so lazy that, for a good long time, you'd see the exact same few recycled photos of counterfeit items being used in item descriptions. No idea if that's changed recently.
Anyway, going back to my main point: I wonder if something about password entry and email address choice serves as an early warning flag.
I'd kinda be surprised, but I could imagine it potentially being useful.
Which would explain why Ebay would be secretive. Because the detection is easily mitigated if attackers become aware of the detection.
But to what end? A valid password is a valid password whether it comes from user that takes 2 minutes to type it in, a password manager, or a bot.
Of course you can't trust anything from the client and both methods are subject to tampering, I'm not sure which is more tamper resistant.
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.
Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?
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.
I prefer seeing one system or the other, but not both.
If you have rules, don't use a password strength meter. Rules are going to be a binary result - "yes the password is good enough", or "no, this password is not acceptable" - which is represented by showing which rule(s) were not respected by the user, or a green checkmark.
A password strength meter can be used when there are no rules enforced, to let the user decide for themselves whether that red progress bar showing a weak password is good enough for their needs. The meter doesn't need to be binary, with red/orange/yellow/green stages. The only reason I don't like password strength meters in general is that there is no standard across sites/services as to what constitutes a strong password. One site will show "password123" as weak, while another will say it's fairly strong. Each implementation has its own arbitrary algorithm that is likely not representative of "true strength".
zxcvbn is actually a great password strength library, JavaScript, client-side, and only about 400 kB or so last time I checked (compressed, including (!) dictionaries). It was developed by a Dropbox engineer for the password setting/changing dialog at Dropbox, and open sourced, if I'm not mistaken.
Again, this is a great tool, client side, small (smaller than most webpages and adds these days at any rate), and it also allows to provide a list of "custom black list words" not to use in the password (e.g. username, site name, etc.).
AFAIK, zxcvbn really is the gold standard here.
Given this, I don't really see how a server-side check is better or necessary. Ebay really ought to provide a much better answer than "trust us" here.
Besides, the password strength js can easily be loaded async.
As an aside, I have always wondered how it is possible to disallow reusing previous passwords if the password is only saved on the server as a salted hash, which is recommended I believe.
Is it possible?
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.
[0]: https://twitter.com/signupI 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).
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.
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.
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"?
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' -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' -H 'Content-Type: application/json' -d '{"input01":{"Input":"Passwd","Passwd":"GoogleBatteryHorseStaple","PasswdAgain":"GoogleBatteryHorseStaple","FirstName":"Hacker","LastName":"News","GmailAddress":"i-have@none.yet"},"Locale":"en"}'
"Sending each character of your password to the server, before you explicitly agree to submit" is quite another.
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.
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.
(But part of what makes it OK to have more people with access to the logs is you don't put things like username/passwords for all of your customers in the logs.)
In general don't log sensitive information because you don't know how those logs will be used.
From PaloAltoNetworks website:
"... firewall proxies outbound SSL connections by intercepting outbound SSL requests and generating a certificate on the fly for the site the user wants to visit."
It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.
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...
"It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin."
I may use openpgpjs down the line for private messages within rooms. I also want to experiment with WebRTC for private messages and maybe offer some opportunistic peer to peer connections but I haven't gotten the far yet.
Will pay attention to what certs are being served from now on...
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?
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.
If the GET is being sent via XHR over SSL, how is doing a POST any more secure?
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.
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.
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 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
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.
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
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.
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.
The ideal way to deal with passwords would be something like SCRAM [1], but you are adding a bunch of complexity on the client side, and you'd need to trust your JS libraries.
[1] https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
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.
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.
Client-side password strength checker would make it functionally impossible to check dictionaries.
Thus, it is, as a matter of fact, quite possible to do reasonable password strength checking on the client side with a footprint that's a small fraction of many of today's ad-infested websites.
I guess that's one way to coerce the user into enabling Javascript, at least temporarily.
Also, like, if they're sophisticated enough to be doing that, they should probably get the basics right.
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.
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.
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.
In general though, yeah, not that exciting of an article.
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.
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.
Edit: They do also send GET ... that is worse.
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.
"dozens" maybe?