4 ms·

What now? You're statement is a little confusing. All our passwords are munged with encryption, they all look like hash garbage. How could they differentiate?

What now? You're statement is a little confusing. All our passwords are munged with encryption, they all look like hash garbage. How could they differentiate? My only guess is that perhaps you've interpreted my comment as a database entry, rather than a UI progression--and you think that "%1 off coupon" is stored with the login table. That clearly wasn't what I was saying--thats a poor design. I'm saying simply offer a coupon code to users if their password validates certain levels of difficulty. It doesn't need to be tied to the account in anyway. Also, I think that at the point of my database being in the wild, I'd think hackers will be less focusing on cracking a stored password and more interested in trying to restore the encrypted payment details?

ktsmith 16y ago
If your database is in the wild and you give a discount based on password strength they could look at the first order for each account and start working on the hashes associated with the smallest discounts first knowing those would be the weakest passwords.
pavel_lishin 16y ago
> I'm saying simply offer a coupon code to users if their password validates certain levels of difficulty. It doesn't need to be tied to the account in anyway. Ah, my assumption was that the entire DB was in the wild, and that every user had a unique discount code they could use once. And why are you storing payment details, anyway?