3 ms·
I think every entity which holds a password should adopt the same policy: from the moment the password is created, the entity will undertake to do everything it
by pjbster 8y ago
I think every entity which holds a password should adopt the same policy: from the moment the password is created, the entity will undertake to do everything it can to try and break it. Whatever it takes - bot farms, 3rd-party white hat outfits, social engineering in the canteen, whatever. Anything (legal) goes.
Once the password is broken, the account will immediately be placed in suspense until the owner creates a new password. Which, of course, immediately gets fed back into the machine and life goes on.
This would eliminate password rules. If you want to create a password which consists of, say, 100 consecutive zeros, go for it. But you might only get to use it for a fraction of a second if the network can break it quickly.
- nsgi 8y agoI can see a few problems with that approach: - It's already fairly straightforward to predict how easy a password will be to crack e.g. if you're going to bruteforce dictionary passwords or those with predictable combinations of characters, why not just include those in your password blacklist? - Randomly suspending users' accounts and telling them to change their passwords is going to annoy them (especially if it happens repeatedly) and consume support resources - It's overkill unless the service is security critical - How easy a password is to crack is partly a function of the hash algorithm and salting the entity uses so it may not be the user's fault their password gets broken