51–60 of 111 posts
Not that lolcats are bad. They are good. It's just they aren't fun anymore once your identity is stolen. Or your mom's.
Earlier quoted context omitted.
> Get a whole heap of passwords from random.org. I suggest /dev/random or /dev/urandom, as it doesn't involve a third-party. You can xor with data from random.org, if that makes you feel better. > Forget the password to the encrypted text file? Throw your life away and start a new identity. Just print out the plaintext of your password text file, and store the piece of paper somewhere reasonably secure. I say `reason…
I'm not too fond of printing out passwords. If I forget, and I'm extremely forgetful, that's just a disaster waiting to happen. I know my brain and I know it can't be trusted with physical security. Also, I'd rather use /dev/urandom instead of simply /dev/random. Considering my aversion to using a stranger's computer to login to my accounts and the fact that I never use an open WiFi connection for anything without To…
Any user input needs to be filtered, sanitized, validated and limited. Please be my guest and pass any user input to your magic hashing function, don't cry about it later because due to some special circumstances / framework bug / language bug / buffer overflow / extra hidden utf char, your magic function opens a huge security hole. oh oops.
Passwords are bullshit. We should have a start-up about having a better way of keeping your digital identity other than hundreds of logins/passwords, but obviously everyone is too busy with figuring out better ways of sharing lolcats. Not that lolcats are bad. They are good. It's just they aren't fun anymore once your identity is stolen. Or your mom's.
I'm sure they could use your support :-)
Ah, yes, there's nothing quite like a condescending representative entirely out of his depth telling you to "do the maths" to show your customers that you really care about their security and privacy. I wish you good luck in getting them to listen to you.
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…
No, that just means your password manager sucks and is out of touch with the real world. Any good password manager lets you quickly generate passwords of any length.
Earlier quoted context omitted.
Again, the point isn't about whether 12 is enough. It could have been 64 and the point would still stand. The OP's point is that limiting password length (to anything less than 1000 or so) is usually done to be able to set a maximum length on the password column of a database. Password hashes, on the other hand (including bcrypt), produce fixed-length hashes, regardless of the input size.
bcrypt has a 50 char limit. You could always prehash(sha256) the password before passing it to bcrypt.
The source provides a hint:
/* Schneier specifies a maximum key length of 56 bytes.
* This ensures that every key bit affects every cipher
* bit. However, the subkeys can hold up to 72 bytes.
* Warning: For normal blowfish encryption only 56 bytes
* of the key affect all cipherbits.
*/
[2] http://security.stackexchange.com/questions/21524/bcrypts-72...