------------------------------------------------------------------------------- Rules of Cryptography First rule of cryptography and password storage is "don't invent it yourself,". But if you must here is the absolute minimum you must do to have any semblance of security: Cardinal rules: 1. Do not invent your own "clever" password storage scheme. I know, you're smart, and you grok this crypto stuff. But through this door lies madness. 2. Never store a plain text password (which means you can never display or transmit it either.) 3. Never transmit the stored representation of a password over an unsecured line (either plain text, encoded or hashed). 4. Speed is your enemy. The slower it is the better! 5. Regularly reanalyze and improve your process as hardware and cryptanalysis improves. 6. Cryptography and processing is only a very small part of the solution. 7. Points of failure include: storage, client, transmission, processing, users, legal warrants, intrusion, and administrators. Steps: 1. Enforce some reasonable minimum password requirements. 2. Change passwords frequently. 3. Use the strongest hash you can get - SHA-256 was suggested here. 4. Combine the password with a fixed salt (same for your whole database). 5. Combine the result of previous step with a unique salt (maybe the username, record id, a guid, a long random number, etc.) that is stored and attached to this record. 6. Use a cryptographically secure hash, multiple times. Run it enough to take at least a second on a good machine. Speed is your enemy and multiple iterations reduces the speed. NOTE: The MD5 hash was designed for speed, and speed is the enemy here. Oh, and unless you are running SSL or some other line security then don't allow your password to be transmitted in plain text. And if you are only comparing the final hash from the client to your stored hash then don't allow that to be transmitted in plain text either. You need to, then send a nonce (number used once) to the client and have them hash that with their generated hash (using steps above) hash and then they send you that one. On the server side you run the same process and and see if the two one time hashes match. Then dispose of them. There are a better ways, but that is the simplest one. ------------------------------------------------------------------------------- Secure Wiping of data shred overwrites the data multiple times before actually deletion overwrite http://www.kyuzz.org/antirez/overwrite.html For whole disks Darik's Boot and Nuke http://www.dban.org/ ------------------------------------------------------------------------------- The Perfect Crypography... There is a perfect method of cryptography, that is unbreakable, even with brute force attacks. The one time pad. Basically XOR with a purely random key that is the same length as the message being encrypted. Without the key, a brute force attack can only decrypt the message to anything, not nessarially the original message. For example. Take a well known book, and use it as the encryption key! One famous one time pad is the King James Bible. It is however important that the key only be used once, and once only. Repeated use will make the key vulnerible to discovery by comparing multiple encryphered texts. The real problem is that a key of that length is as long or longer than the original message, and thus becomes unmanageable. As it is unmanageable, you need to store it and thus the key could be easilly stolen or in the case of public properity (like a book), it becomes known as being the key used. Also you would need to ensure that the key never changes while the message may be needed. If it does, the message can be no longer be deciphered. This is why almost all cryptography using some type of hashing function to convert a cryptographic key of reasonable length, into a long sequence that is combined with the message to encrypt/decrypt it. ------------------------------------------------------------------------------- Preventing Brute Force Cracking. There certain things that can prevent the use of brute force in decrypting messages. 1/ Longer Cryptographic Keys (that is pretty obvious) 2/ The cryptographic process being known precisely. (security by obscurity) 3/ The 'clear-text' that is not very 'clear' (second hidden encryption) Brute force attacks require the resulting decrypted text to be reconisable as being decrypted. If it is not recognised it will not flag it and thus move on to the next key. If the actual method of encryption/decryption is not known then no brute force attack will ever generate clear-text. But if the clear-text is not actually clear. That is it has no recognisable order to it, then it is not going to be flagged either. So if the 'clear-text' of the encryption is itself an encryption, or unrecognized compression, or some other text randomization method, then the brute force method can never know when it has even succeeded! The key to this to some how ensure that there is no identifiable marks or pattern is in the message, that will identify the encryption or compression, AND that the method of encryption is itself kept secret, or changing. That is not only should the key be kept secret, but all aspects of the encryption itself should also be kept, as secret as posible. But without actually relying on it for the over all security. This however is difficult to do in any public distributed encryption program. After all the decrypting process needs to know how to decrypt a message! ------------------------------------------------------------------------------- pwc.pl A 3 line perl password cracker #!/usr/local/bin/perl -- -pwcracker-in-3-lines-of-perl-plus-disclaimer $u{$p[1]}=$p[0] while(@p=getpwent);while(<>){chop;foreach $c (keys %u) {printf "u=%s p=%s\n",$u{$c},$_ if(crypt($_,$c) eq $c);}} # Use: pwc dict ... ------------------------------------------------------------------------------- For random numbers see ../shell/random.hints -------------------------------------------------------------------------------