4 ms·

Personally I love it, however I will never ever be able to employ it on our company website. However, the concept of incentivizing the password entry field has

Personally I love it, however I will never ever be able to employ it on our company website. However, the concept of incentivizing the password entry field has inspired me. Instead of something risqué like nudity, how about offering a coupon off your first order (works for a commerce or service based site). Ie, as they type, gradually increase a % from 1 to 5 (or higher, what ever you're willing to offer). IE, a progression like: |asdf | |asdf12 | %1 off first order coupon |asdf12KL | %2 off first order coupon |asdf12KL.!| %5 off first order coupon

tsycho 16y ago
That's a very smart idea. Even if you cannot give discounts, maybe you can give out free support, extra services (eg: extra storage for a Dropbox like service).
pavel_lishin 16y ago
And when your database is out in the wild, it'll let crackers know exactly which passwords to go after first, and which ones not to bother with!
- giberson 16y ago
  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?
T-hawk 16y ago
In addition to the business cost of giving away discounts, are you accounting for the business cost of increased support incidents for forgotten passwords? (Good idea though)

tsycho 16y ago

That's a very smart idea. Even if you cannot give discounts, maybe you can give out free support, extra services (eg: extra storage for a Dropbox like service).

pavel_lishin 16y ago

And when your database is out in the wild, it'll let crackers know exactly which passwords to go after first, and which ones not to bother with!

giberson 16y ago
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?

T-hawk 16y ago

In addition to the business cost of giving away discounts, are you accounting for the business cost of increased support incidents for forgotten passwords? (Good idea though)