web-security methods, advice please!

[Madison Kelly]

Lennart Sorensen wrote:
>> SHA256 base64 hash. I repeat this step 40,000+ times on my old laptop 
>> (will do it more on the server when I am done). (reasoning behind this 
>> step here: http://en.wikipedia.org/wiki/Key_strengthening ).
> 
> Whatever is the point of all the repeated work?  If the hash is any
> good, doing it once is sufficient.

The idea, as I understood it, was to force a brute-force attach to try 
X-number of hashes per password, slowing down a brute-force attack to 
about 1 password/second. It may be overkill though, specially because of 
the server-side CPU resources required...

>> - After this, each time the user calls the program, I:
>>   - Read their UA string and their IP address.
> 
> I recommend NOT including the users IP in the check.  IP addresses can
> change often, even during a session for perfectly good reasons.  If I
> was on dial up and my connection died and I reconnect and get a new IP
> form the provider, that is not a good reason for any sessions to stop
> working.

If you were on a website that was storing your personal info (ie: 
financial data, CC numbers, etc) would it not be worth having to log 
back in after a dropped connection for the extra security? How do banks 
handle this? (I don't use web banking). Would there be an alternative 
string I could/should use that would be hard for a cracker to duplicate? 
I worry about just using the UA because it is so easily spoofed.

>> Again, *Please* be brutal on your critiques of my methods. If my 
>> thinking is flawed, I would be grateful to learn now rather than later. :)
>>
>>   Also, I don't believe in security through obscurity in the slightest, 
>> so if my methods can't survive being exposed, I'd also rather know now. :)
> 
> So why not simply use the same password storage hash system as your
> system uses (I believe MD5 hashed passwords are the most commen since
> the old unix crypt was limited to 8 character passwords)?  There already
> exists code for it, and if it is considered secure enough to encrypt
> your root password on the server, you would think it is good for the
> password storage of your web page users too.  Why reinvent the wheel and
> use code that no one else does, meaning code that no one else will check
> for bugs and maintain.

MD5 and SHA1 have been compromised.

http://en.wikipedia.org/wiki/Md5

"In 1996, a flaw was found with the design of MD5; while it was not a 
clearly fatal weakness, cryptographers began to recommend using other 
algorithms, such as SHA-1. In 2004, more serious flaws were discovered 
making further use of the algorithm for security purposes questionable."

http://en.wikipedia.org/wiki/SHA

"It [SHA1] was considered to be the successor to MD5, an earlier, 
widely-used hash function. Both are reportedly compromised.

The other four variants (SHA-224, SHA-256, SHA-384, and SHA-512) are 
sometimes collectively referred to as SHA-2 functions or simply SHA-2. 
No attacks have yet been reported on the SHA-2 variants, but since they 
are similar to SHA-1, researchers are worried, and are developing 
candidates for a new, better hashing standard"


*nix systems that use '/etc/shadow' use a random 2-byte salt and add it 
to the user's password when (re)set before the hash is generated. Then 
the salt is thrown away. When a user tries to login, their password is 
run through (up to) 4096 combinations until either the proper hash is 
matched of the number of possible salts run out and the password the 
user supplied was deemed to be wrong. This slows down a brute-force 
attack a bit, but not much. So a person wanting to crack into a *nix 
system (assuming they have access to the password hashes from 
'/etc/shadow') wouldn't need to try very hard with an MD5 rainbow table 
if the user's password was otherwise weak.

This is why I didn't want to duplicate the *nix shadow file method. It's 
not very secure anymore.

I do agree though that using my own code isn't ideal, for exactly the 
reasons you mentioned. Perhaps there is some more tested canned code I 
could use?

Thanks for your feedback!!

Madi
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists