 |
 |
On 06/13/12 16:30, Carl Bussema III wrote: > Actually LastPass is a well-known and respected security tool, so I > would actually trust them not to compromise the password. I actually > tried to decipher the HTTPS session with Fiddler, but Chrome + > LastPass detected a man-in-the-middle and wouldn't proceed. > > And because apparently some people need to be put out of their > paranoia, I went ahead and just used my regular developer tools and > found exactly what I suspected: > > I posted the password "asdf" to their form. I then watched the AJAX > request (which because it happens client side is unencrypted before > transmission) ... and you know what they are sending to their servers? > THE HASHED PASSWORD. It's not like it's hard to SHA1 a string > in JavaScript. > > So the send the hash to the server, check the list of "known bad > hashes" (which is what the hackers have published) and tell you if > your password hash matches a known compromised hash. > > It's really about as safe as you can possibly imagine and a great > tool. Yes, we should be careful about inputting passwords onto strange > sites, but you should also do your due diligence and check if the site > might actually be legit. > > /rant > Passwords are about as fragile a thing as there is today: users pick and display idiot pw's, and system (often) have bad security measures in place which don't really work. LastPass is likely an up-front honest entity, but that isn't the reason why they shouldn't be used. Trusting another entity with your pw increases the attack surface of the product you are testing. As good as LastPass is, your are now trusting them to be really secure. That they throw away the string you enter is good, but that means that vandals know just where to look if they were trying to break that system. This is a philosophical thing. Minimizing the places on the net that have pw's is a good thing. --STeve Andre'