11–20 of 111 posts
Of course, there's no good reason to limit passwords to any length.
Banks are typically the worst. All sorts of gimmicky password requirements. 8-12 characters. Must have one capital letter. Must have one number. No special symbols.
So "I can't believe it's not butter!" won't work, yet that would probably be a pretty secure password, and be entirely rememberable. In fact I could come up with a silly pun-filled sentence for each site I visit and make passwords fun again.
As I see it, character limits aren't so much about security, as just a dumb way to be hostile to the user. All of my passwords are site-specific unique passwords generated by a password manager. I don't care if you store plain-text passwords, because if someone steals passwords out of your database then they already have all the access that my password to your site would've given. But if a site rejects the password t…
As I see it, character limits aren't so much about security, as just a dumb way to be hostile to the user. All of my passwords are site-specific unique passwords generated by a password manager. I don't care if you store plain-text passwords, because if someone steals passwords out of your database then they already have all the access that my password to your site would've given. But if a site rejects the password t…
Isn't there research out there that proves long sentences and phrases are better than any random alpha numeric password
Forget your password? Once you reset via email, as soon as you get access to that encrypted file, get a new random password and reset it again. Save the new password in the encrypted file.
Password managers often connect to the internet to retrieve your passwords so if you lose your access, you're SOL. I also wouldn't trust a browser plugin as that may be prone to compromise. Backup to your laptop or something if you need to take it with you, but keep it encrypted until needed.
Forget the password to the encrypted text file? Throw your life away and start a new identity.
Edit: Pointed out below (and I agree whole-heartedly) use /dev/u(a)random
And idupree's points are spot on.
Technically, if they are using bcrypt hashes with a high enough work factor, and salt then with something like UserID, then 12 characters is pretty damn secure even if their whole DB gets leaked. Of course, there's no good reason to limit passwords to any length.
Not to mention that a 30-char purely alphabetic passphrase such as xkcd.com/936 is so much easier to remember (i.e. less likely to be written on a post-it note) and type into today's mobile devices (i.e. more likely to log out properly, because it's easier to log in the next time) than a 12-char password with two numbers and one symbol in it. What I'm trying to say is that there is more to password strength than the time it takes for a botnet to brute-force it. Humans are the weakest link in most security systems. If you want strong security, you need to design your system so that humans can interact with it without too much mental strain.
Nowadays, anything less than [\x20-\xFE]{8,64} is just a lame excuse for storing passwords in a plain-text VARCHAR field without proper escaping. Therefore, if your password policy as any more restrictive than [\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-text VARCHAR field without proper escaping.
I blogged about week ago: Some funny stuff for a change: I told my colleagues that we receive at least 5000 "hack attempts" aka failed logins daily to any of our public Internet facing servers. One of my colleagues just said to me: "Well, you're having such a password policy, that maybe those are actually failed login attempts and not hack attempts at all." - It really got me laughing. Yes, passwords, especially long…
Technically, if they are using bcrypt hashes with a high enough work factor, and salt then with something like UserID, then 12 characters is pretty damn secure even if their whole DB gets leaked. Of course, there's no good reason to limit passwords to any length.