Banner
Views: 236,560,524
Time: 2013-05-24 02:01:53 PM
18 users online: bandicoot, o Doopy Buckride, o Ersanio, Grav, HyperMario, hypershadic, Lithuanian Dude, Mariohacker14, metalgearhunter, mrdeppelman, phenolatukas, Purple Rex, RaindropDry, o ShadowPhoenix, supernova38, Thomas, o Undy, Vanya - Guests: 155 - Bots: 14Users: 22,881 (1,274 active)
Latest: Shizufuzu
Tip: Unique level names aren't necessary, but they're a plus.
Cryptographic hashing of valuable data
Forum Index - Hobbies - Computers & Technology - Cryptographic hashing of valuable data
Pages: « 1 »
(Not sure if this should be in programming)

At college I'm working on a site for a "customer". The site is an auction site, has a database and all (runs on SQL server/mssql (?), NOT mysql), and I had the idea of hashing valuable data such as password, secret answer to secret question and all in case the database somehow gets compromised. However the instructor said that hashing data "wouldn't work out"/is pointless, and told me to look into data hashing theories and all. I've done so, but I can't see why it "won't work out". Maybe I didn't look hard enough, but anyway...

As far as I know, encryption can be reversed automatically, but hashes requires stuff such as rainbow tables which should take a longer process if you have a very random salt.

So my question is, is hashing password data useful at all? I mean, if someone compromises the database and can see the actual passwords of certain users, they can use the passwords on other sites and all. Hashing passwords would prevent that. Are there any other advantages of hashing password data?

If I hash the passwords though, I'd have to stick to a password reset system instead of a password recovery one. Are there disadvantages to a password reset system compared to a recovery one?

In case hashing of valuable data really does have a point, then which hashing method should I pick? I mean, there's SHA-1, SHA-256, MD5, etc etc. Which one is the best?

It'd be awesome if someone shed more light on this.
Last edited on 2011-09-09 06:33:51 AM by Ersanio.
Salting and hashing is not as pointless as you think. To begin with you'd be a douche site developer not to salt and hash the passwords. Another thing that makes it more powerful is that if you got your website source code safe, you can do a lot to "scramble" the password and make your hashes safer.

And don't ever include a recovery system, those only prove that the passwords are not stored safe. A reset system is much more clever. (And if you got a bad recovery system, a "hacker" could get hold of a password that could be used on other websites)
Advantages to hashing passwords:
1) Keeps passwords confidential.
2) Localizes any database leaks, preventing direct control of customer passwords.
3) Minimal effort providing a heavy load of security, I'd take it.
4) If you immediately hash the password and then unset original password it prevents possible non-SQL leaks.
5) It keeps password column at a fixed length, which in some SQL systems can lead to small improvements(Extremely minor but not negligible on the large scale).


Also SHA-1 is sufficient for your needs, though any level of SHA is fine. Password resets are far smarter in the long run, after all they forgot that password once.
Alright, thanks for the replies. It seems like I have something to discuss with the instructor next week.

I'm looking forward to it, heh.

e: more thoughts are still welcome of course.
Last edited on 2011-09-09 06:52:21 PM by Ersanio.
I've done a bit of work on file encryption/compression myself, so I'm fairly sure I'm qualified to throw in my two cents.

If you need to have a large amount of data encrypted so that the encryption is reversible and not spend tons of time wrestling with code, I'd recommend running your data through a Burrows-Wheeler transform or a Move-To-Front transform. Both of these options are a fairly simple encryption that would prevent raw sensitive data from being stored in database.

Of course, this is completely impractical for simple password storage, but for larger private data fields this might be a considerable idea.
Originally posted by Noobish Noobsicle
I've done a bit of work on file encryption/compression myself, so I'm fairly sure I'm qualified to throw in my two cents.

If you need to have a large amount of data encrypted so that the encryption is reversible and not spend tons of time wrestling with code, I'd recommend running your data through a Burrows-Wheeler transform or a Move-To-Front transform. Both of these options are a fairly simple encryption that would prevent raw sensitive data from being stored in database.

Of course, this is completely impractical for simple password storage, but for larger private data fields this might be a considerable idea.



This information seems hardly if at all relevant to the topic. Compression for one, does nothing to help the password storage integrity. Encryption is at least sort of on the right track however, hashing still had a far superior upper hand here. The point of hashing is so that you can NOT reverse engineer the password(without a massive amount of CPU power).

For larger private fields you wished to be able to reverse, encryption is the way to go. However neither of the two methods you posted are sufficient in the least for encryption. Two fish or Rijndael are the methods you would generally look at for heavy duty encryption. Either of these alone is insufficient though, you also need a way to protect the key. If they key is stored plain text then a hacker can easily reverse the encryption, hashing the key would render it useless though. So you would need to be careful and take the key based on the users password and validate against the hash, then decrypt the data using the key. After the data is decrypted the password should be immediately overwritten and unset.

Again though, these methods are for protecting sensitive data. You would not use these alone for protecting a password, more like protecting data that is protected by the password. Also both methods listed by Noobish Noobsicle are transformation steps used in various compressions, which is hardly encryption.
Well, problem solved. I've talked with my instructor.

It was miscommunication from my side - I told him that we'd hash "important data", but I never defined what this "important data" is. Anyway, he seemed to agree with the password-hashing idea.
Pages: « 1 »
Forum Index - Hobbies - Computers & Technology - Cryptographic hashing of valuable data

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To Us


Total queries: 27

Menu