6 ms·
> 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
by 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 agoTiming? Perhaps they are timing the typing speed in some way.
- lsaferite 10y agoWell, that's going to trigger on a large group of people that use password safes.
- Artlav 10y agoHow 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 agoThis 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 agoMy guess is that they're doing bot detection or something similar using thing like the additional timing information and detection of typing errors.
- wimagguc 10y agoBoth 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.
- okreallywtf 10y agoIf this was the case, I would think that a single request where they record the timing between characters clientside and post that timing information along with the password would work better. Timing incoming POST requests as part of a single password reset "session" seems fraught with problems, I can't see how you could really trust the timing numbers you would get. I type my password pretty fast generally and I wouldn't be surprised if the margin of error on that timing is a significant percentage of the average time per key press. 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.
- Splines 10y agoBut then what about people who rely on password autofill and password manager ctrl+v users?
- parandroid 10y agoThis 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.
- reitoei 10y ago> 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. Ebay is not a two bit software startup, it's an eCommerce powerhouse with extensive QA processes.
- parandroid 10y agoI am well aware of that, and agree with you. There had to be some seriously bad decisions made here, and it certainly doesn't look like someone from a big company would make such mistake. 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.
- anentropic 10y agothat doesn't mean they don't have bad implementations
- gedrap 10y agoYeah, but being a powerhouse doesn't mean they don't introduce silly bugs. They do. E.g. on Facebook, a year or two ago, you could use dev tools and change hidden input field's value when writing a post and post to anyone's timeline (this story got tons of coverage for a bunch of reasons, vulnerability itself not being the prime one). Does it seem like a silly bug? Definitely. But it happened, it's not the first one, not the last one. So it's a bit naive to assume devs at popular companies don't make bugs, they are superhumans, etc :)
- TorKlingberg 10y agoThey 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.
- arviewer 10y agoYou can use a client check to check for the basic requirements, like minimum and maximum length, characters required or allowed etc. Then when the user submits his password, you can do a serverside check.
- developer2 10y agoThe reason for using a server-side solution is for a password strength indicator. You need the full algorithm to run against the current entry, and every user-friendly implementation does this on every character input so you know when what you have typed is "strong enough". I'm not particularly a fan of password strength indicators in general, but if you're going to do it at least do it cleanly.
- czinck 10y agoIs their algorithm so complex that it can't run in a reasonable time using client side javascript? I have trouble thinking of anything that isn't vastly over-engineered and runs slower than the network lag probably is.
- ncallaway 10y agoNo, it's more about leaking information to the JS client. If, for example, their password verification rules stipulate that you can't reuse any of your last N passwords, then they would need to make this check server-side as they don't want to provide that information to the client.
- 10y ago
- vmateixeira 10y agoBuilding a user's password dictionary?
- chiph 10y agoWith common misspellings.
- mootothemax 10y ago>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? 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.
- gnur 10y agoI guess that fraud could be a big part of this, getting every character in sequence says way more about the end user then getting only the password in the end. I wonder how this will affect password manager users though.
- laumars 10y agoThat might be it. They might use it to detect if someone is pasting a password in vs typing one in. Which might help identify against bots / attackers stealing someone's ebay account. Which would explain why Ebay would be secretive. Because the detection is easily mitigated if attackers become aware of the detection.
- MaDeuce 10y agoSame thought here. I was imagining that some sort of timing analysis / fingerprinting could possibly be going on. 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.
- amichal 10y agoNot a good enough reason, or sane, but what if it's a honeypot of sorts. Perhaps eBay is using the timing information themselves to flag hack attempt sources...
- deleted 10y ago[deleted]