161–170 of 220 posts
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-a... Checks out, password is in the GET param.
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?
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... 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…
Earlier quoted context omitted.
This might get downvoted because it's just a link, but: 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 mo…
You can do a lot of server round trips before you reach 400 kB.
Besides, the password strength js can easily be loaded async.
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-a... Checks out, password is in the GET param.
Perhaps I'm missing something, but this BugReplay appears to provide network request information as requests happen in the video. 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?
Earlier quoted context omitted.
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 and TLS https://www.schneier.com/blog/archives/2010/03/side-channel_...
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 th…
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... 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…
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.
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-a... Checks out, password is in the GET param.
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…
This is probably secure, but non standard password exchanges open up a lot of possibility's.
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, no…
> 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?
Earlier quoted context omitted.
But there is a good chance that these GET parameters are logged by the webserver. Even if these servers are very secure and strictly monitored, one bad employee can cause a lot of trouble.
Perhaps, but an employee in that position can steal credentials even without GET logs. 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…