|
Never mind proper cryptography --- I've had a cable internet provider's 'forgot password' feature e-mail me what was clearly a password I entered, so they were storing it plaintext. Plus, it was all lowercased, so they're likely doing case-insensitive comparisons, too. Then there are websites that insist that your password not be longer than 8 characters, or that complain about using non-alphanumeric characters, etc. I really have to wonder what would cause someone to do that -- SQL field of 8 chars?
|
# ? Dec 18, 2010 04:30 |
|
|
# ? Jun 13, 2024 06:00 |
|
ShoulderDaemon posted:not write your own cryptographic protocols. Don't implement your own crypto either. (aside: Nintendo made an awesome mistake and used strcmp instead of memcmp to check signatures for drm)
|
# ? Dec 18, 2010 04:31 |
|
OddObserver posted:Never mind proper cryptography --- I've had a cable internet provider's 'forgot password' feature e-mail me what was clearly a password I entered, so they were storing it plaintext. Plus, it was all lowercased, so they're likely doing case-insensitive comparisons, too. Then there are websites that insist that your password not be longer than 8 characters, or that complain about using non-alphanumeric characters, etc. I really have to wonder what would cause someone to do that -- SQL field of 8 chars? If it's DES like Gawker, 56 bits is only enough room to hash the first eight characters. Fun huh? It totally baffles me how someone can actually choose DES these days when it was proven to be brute forced back in the mid 90s even. Or hell, why it's even an option in crypto libraries. Oh yeah :php: Deafults to DES I think, can't make heads or tails of this poo poo. http://php.net/manual/en/function.crypt.php Here's a fun one: quote:As of PHP 5.3.0, PHP contains its own implementation and will use that if the system lacks of support for one or more of the algorithms. Going back to DON'T WRITE YOUR OWN CRYPTO. Knowing the terrible quality of PHP devs it's probably loving horrible.
|
# ? Dec 18, 2010 04:51 |
|
Fwiw, it's someone elses des crypt implementation: http://svn.php.net/repository/php/php-src/branches/PHP_5_3/ext/standard/crypt_freesec.c Took me a while to find it, amongst all the bug reports that crypt changes output across versions and platforms. php: all the portability of C with none of the type safety tef fucked around with this message at 05:18 on Dec 18, 2010 |
# ? Dec 18, 2010 05:16 |
|
I pretty much assume that any password I use for a website that isn't a bank or something that hires real auditors could be hacked and stolen. Doubly so if the site was written in php.
|
# ? Dec 18, 2010 05:26 |
|
tef posted:It depends on the hash, but most are built on the Merkle–Damgård http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction I think the whole google or facebook cross login thing is one of the coolest things out there and may have long term benefit because they don't do stupid poo poo. I kind of wish my work used it for remote login!
|
# ? Dec 18, 2010 05:27 |
|
tef posted:This is why I think authentication and passwords should be handled by frameworks entirely -- it is far, far too easy to break poo poo. What framework would you recommend for Java in the case of wanting to store users passwords.
|
# ? Dec 18, 2010 07:02 |
|
No experience personally with java web frameworks. Why not hand authentication off to some authentication daemon ? (pps what is your threat model? )
|
# ? Dec 18, 2010 07:07 |
|
Cryptography is so hard that I didn't even realize that I was rolling my own.
|
# ? Dec 18, 2010 11:48 |
|
So since we're on the topic of password security, even though it's off topic I thought I'd try to check whether my understanding of what I do currently is correct. (This is distinct from checking whether what I do is correct, which it isn't.) My site currently computes an MD5 hash for each user's password. Each user has a different, randomly generated salt. But the method used to do this is quite fragile: I just use a call to PHP's crypt() function to generate the salt and the hash when the password is first supplied. (The documentation states that if no salt is supplied, a random one is generated.) That would be fine but whether PHP uses MD5 or DES is determined by the version of PHP and by the system it is running on. It could be that PHP might end up using DES. The hashing scheme that PHP will default to is indicated by a constant CRYPT_SALT_LENGTH. So in a configuration file I have a line checking that CRYPT_SALT_LENGTH is equal to 12. If it is not then a bland error message is displayed and my scripts refuse to run at all. This seems to work as intended, because all the stored passwords in the database start with $1$, and the first 12 characters are different in each field. The documentation indicates that this is how an MD5 hash should start, and that the salt appears at the start of the hash (so the salts are indeed all different). But this is a fragile way to do things because if my host changes PHP versions or I move my site then it could suddenly break and I'd have to change the code for creating and checking passwords. It's also my understanding that better hashing-schemes are available than MD5. So the planned remedy for this is to 1) introduce a column in the database that indicates which hashing-scheme is being used for the password. (At the moment if I did this, the values would all be 'MD5'.) 2) implement a constant that states the current "preferred hashing-scheme". If someone logs in and their password is currently not stored using the preferred hashing-scheme, then since they've supplied their password, it can be hashed again to obtain a hash in the preferred hashing-scheme. The password and hashing-scheme columns in the database can both be updated. 3) implement code that generates random salts of the appropriate type. PHP's crypt() function does this, but only if you are using the default hashing scheme. If I wanted to use blowfish or AES then I would have to generate the salt myself, or operate without a salt (not acceptable). 4) switch to using a better hashing-scheme than MD5.
|
# ? Dec 18, 2010 16:04 |
|
Hammerite posted:So the planned remedy for this is to
|
# ? Dec 18, 2010 16:39 |
|
Aleksei Vasiliev posted:Any remedy has to keep compatibility with the existing set of passwords. I may adopt bcrypt() as the better hashing-scheme in (4), but the other steps are needed because I can't upgrade a user's password to a new hashing-scheme unless they obligingly log in and let me see their actual password. There will be users who have lost interest in the site and will never log in again; I'll be stuck with these users' passwords having MD5 hashes. So the other infrastructure to support the superseded, older form of password hashing has to be a part of the solution.
|
# ? Dec 18, 2010 16:48 |
|
Hammerite posted:Any remedy has to keep compatibility with the existing set of passwords. I may adopt bcrypt() as the better hashing-scheme in (4), but the other steps are needed because I can't upgrade a user's password to a new hashing-scheme unless they obligingly log in and let me see their actual password. There will be users who have lost interest in the site and will never log in again; I'll be stuck with these users' passwords having MD5 hashes. So the other infrastructure to support the superseded, older form of password hashing has to be a part of the solution. Force a password reset on next login? Users that don't log in won't care and be locked out, and those that do can have their passwords updated.
|
# ? Dec 18, 2010 17:20 |
|
Murodese posted:Force a password reset on next login? Users that don't log in won't care and be locked out, and those that do can have their passwords updated. Yeah, the plan is to re-hash the password when a user logs in who has an outdated hash. But if a user doesn't log in, you're saying after a certain amount of time their password should be invalidated? I could do that I suppose, and if they try to log in later display a message asking them to email me from the email address associated to their account. That seems to be setting myself up for extra work, though.
|
# ? Dec 18, 2010 17:37 |
|
Hammerite posted:Yeah, the plan is to re-hash the password when a user logs in who has an outdated hash. But if a user doesn't log in, you're saying after a certain amount of time their password should be invalidated? I could do that I suppose, and if they try to log in later display a message asking them to email me from the email address associated to their account. That seems to be setting myself up for extra work, though. No, make them do the a password reset. Send an email with a new random password, you wouldn't have to do this manually.
|
# ? Dec 18, 2010 17:41 |
|
evensevenone posted:I pretty much assume that any password I use for a website that isn't a bank or something that hires real auditors could be hacked and stolen. Doubly so if the site was written in php. Yeah one of my banks has a character limit for passwords. It's great knowing the golf social networking site my company wrote likely has better password security than my bank.
|
# ? Dec 18, 2010 18:33 |
|
hahahahahahahahahahahahahahahahahahahaha while debugging something: Fatal error: func_get_args(): Can't be used as a function parameter in /[redacted]/sc_geometry.php on line 801 whaaaaaaat
|
# ? Dec 18, 2010 21:40 |
|
Bozart posted:I think the whole google or facebook cross login thing is one of the coolest things out there and may have long term benefit because they don't do stupid poo poo. I kind of wish my work used it for remote login! It's called Single Sign-On or simply SSO, it's not invented by Google nor Facebook and neither of them were even the first, one of the most popular standards at the moment for it is OpenID, which contains two (rather poorly) standardized methods for authentication, namely Attribute Exchange and Simple Registration, there's also a commercial competitor which is basically a bad joke called iNames, which uses XRI:s instead of URI:s (which are not interchangeable). I may have had to work with something related to SSO in recent past.
|
# ? Dec 18, 2010 21:44 |
|
tef posted:It depends on the hash, but most are built on the Merkle–Damgård http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction Then again, if you're attacking a single user, the salt being first actually benefits you, because you can then precompute the salt portion of the hash before doing the dictionary/bruteforce attack. But overall, it doesn't matter much, since it at best gives you a 10-20% improvement in speed. As an aside, the salts in the Gawker leak are a bit interesting. They don't use . or / in the salt, so they only have 3844 out of 4096 possible salts. In addition, the salt allocation is quite lopsided - the most used salt occurs 264 times, while the least used occurs only 24 times. Not sure if it's an artifact of the RNG or the salt generation, though.
|
# ? Dec 18, 2010 22:03 |
|
Sun's tutorial for commandline password masking. Skip to the Making the Code Secure and Reliable section, since their original code used immutable strings to store the entered password. Their "Reliable" code uses a second thread to go back and attempt to overwrite each character as it is entered with an asterisk. This fails if * The user types fast * The thread is running slow * You're at the end of the current line in the terminal * You paste a password (entire password minus last character is revealed) * You press the left arrow key then press delete (entire password minus one character is revealed) It also has an extra asterisk in the prompt.
|
# ? Dec 18, 2010 22:49 |
|
ymgve posted:Then again, if you're attacking a single user, the salt being first actually benefits you, because you can then precompute the salt portion of the hash before doing the dictionary/bruteforce attack. But overall, it doesn't matter much, since it at best gives you a 10-20% improvement in speed.
|
# ? Dec 19, 2010 00:09 |
|
Kelson posted:They're using the first two characters of the username as salt, iirc. Tiny Bug Child posted:each password is salted with its first two characters
|
# ? Dec 19, 2010 00:18 |
|
Hammerite posted:Yeah, the plan is to re-hash the password when a user logs in who has an outdated hash. But if a user doesn't log in, you're saying after a certain amount of time their password should be invalidated? I could do that I suppose, and if they try to log in later display a message asking them to email me from the email address associated to their account. That seems to be setting myself up for extra work, though. You could easily keep the number that need to be reset to a minimum by brute-forcing the most of the ones that don't log in.
|
# ? Dec 19, 2010 00:28 |
|
Xenogenesis posted:Are you sure you're not confusing Gawker with ...poo poo
|
# ? Dec 19, 2010 00:52 |
|
Zhentar posted:You could easily keep the number that need to be reset to a minimum by brute-forcing the most of the ones that don't log in.
|
# ? Dec 19, 2010 00:55 |
|
Hammerite posted:So is it time for a security thread? Title: you don't know poo poo about security, seriously, even if you think you are being humble.
|
# ? Dec 19, 2010 02:37 |
|
Wheany posted:So is it time for a security thread? Title: you don't know poo poo about security, seriously, even if you think you are being humble. A thread about security sounds like a good idea.
|
# ? Dec 19, 2010 15:26 |
|
Old but goodie about security: If you're typing the letters A-E-S into your code, you're doing it wrong.
|
# ? Dec 19, 2010 16:07 |
|
ymgve posted:Old but goodie about security: I stopped reading that after about the second scene, or act or whatever. What an obnoxious way to write.
|
# ? Dec 19, 2010 18:15 |
Uhh, that's how screenplays are written.
|
|
# ? Dec 19, 2010 18:49 |
|
A OBLIVION MOD... posted:Uhh, that's how screenplays are written. It's still obnoxious for getting an otherwise valuable point across.
|
# ? Dec 19, 2010 18:56 |
|
A OBLIVION MOD... posted:Uhh, that's how screenplays are written. quote:The office melts away around them, revealing a starfield hurtling past as if moving at awesome speed. Meanwhile, the conference phone transforms into a UNICORN WITH LASER HORN.
|
# ? Dec 19, 2010 19:07 |
|
A OBLIVION MOD... posted:Uhh, that's how screenplays are written. What an obnoxious way to write.
|
# ? Dec 19, 2010 19:16 |
|
Trolling oDesk and ish finds you some really, really terrible code Some Rails controller action from a photo site: code:
|
# ? Dec 19, 2010 19:47 |
|
Xenogenesis posted:Some Rails controller action from a photo site: What an obnoxious way to write.
|
# ? Dec 20, 2010 00:56 |
|
pokeyman posted:What an obnoxious way to write. That's how screenplay software is written.
|
# ? Dec 20, 2010 01:53 |
|
Lumpy posted:That's how screenplay software is written. code:
|
# ? Dec 20, 2010 02:13 |
|
Hammerite posted:
|
# ? Dec 20, 2010 04:50 |
|
No Safe Word posted:horror found it's from Xenogenesis's post.
|
# ? Dec 20, 2010 16:04 |
|
|
# ? Jun 13, 2024 06:00 |
|
Hammerite posted:it's from Xenogenesis's post. I pretty much just stop reading after a line or two of it
|
# ? Dec 21, 2010 05:19 |