One wall falls, another rises in it's place

**SlyMaelstrom** · 05-05-2011

Originally Posted by Mario F.

What I find irritating is that personal private information is still out there in raw format. I don't know... but everytime I'm doing a customer table(s), I have always hashed last name, address, postal code and phone and email contacts (along with any single CC field). The fact the media always loves a good ruckus around credit card theft, shouldn't stop anyone involved in actually creating these database from using bloody common sense and actually learn how to preoperly identify sensitive information. It's not just the goddamn credit cards, for pete's sake.

Forgive my inexperience with cryptography, but I don't understand how you can hash data that must have its original form supplied in some way in the future... like for instance, names, addresses, and of course credit card numbers...

Once it's hashed, you can't really get it back... even if you know all the details of how it was hashed you still have the pidgeon-hole principle to contend with... it's not like Sony can bill a credit card company with 5af4378e537ed82689b42478e217d547 or tell them "the credit card number is either 4544-1246-6044-6743 or 0543-1325-2352-1402 or 6785-4063-2563-2302, I'm not sure"... I suppose you can do some sort of reversible encryption, but not a hash... not as far as I understand them.

**zacs7** · 05-05-2011

Originally Posted by nvoigt

...
I really wish we could vote for single politicians instead of whole parties...

Didn't Germany run into that snag 60 odd years ago? ;-)

It sounds like Sony forgot about the 10 immutable laws of security... And/or it's probably no co-incidence that these attacks occurred after Sony re-trenched a whole bunch of people, who cares how much security you have if the "hacker" has the keys!

**Mario F.** · 05-05-2011

Originally Posted by SlyMaelstrom

Forgive my inexperience with cryptography, but I don't understand how you can hash data that must have its original form supplied in some way in the future... like for instance, names, addresses, and of course credit card numbers...

Keep in mind we are talking about cryptographic hash functions (like SHA-2), not high-collision hash functions created for purposes other then cryptography. Also, concerning databases, arguably I tend to use it as an umbrella term that includes database encryption services like those present in SQL Server.

**anduril462** · 05-05-2011

Cryptographic hashes by design are one-way functions. There is no feasible way to go from the digest back to the message. If you've found a way to easily reverse these functions, you just turned the math world upside down. Some guys in a black helicopter will come in the middle of the night and raid your house, taking you away to some secret government facility to put you to nefarious use. Using hashes for data like last names only makes sense if you never want to recall the last name, only verify if the user entered the same last name as they did when they were entered in the database. The database encryption services you are referring to use some sort of two-way encryption algorithm (like DES & AES). Whether it's symmetric or not, and whether it's block or stream, etc depends. But two-way ciphers are the only way to feasibly encrypt data and retrieve the plain text from the cipher text.

**Subsonics** · 05-05-2011

Originally Posted by anduril462

Cryptographic hashes by design are one-way functions. There is no feasible way to go from the digest back to the message.

For anything vulnerable to dictionary attacks such as passwords it is feasible by hashing your "words.txt" file that you use for the dictionary attack, hence the salt that was mentioned earlier. I don't see how a credit card number can be exposed by a dictionary attack though.

**Mario F.** · 05-05-2011

Yup. Dunno why I came up with SHA-2. Probably was too hungup on the term "hash" which I tend to use too loosely when discussing database encryption (and hashing) of data. To be clear, hashing CCs and personal data (with the exception of passwords) is not what I mean to say, unless the system includes the requirement for the user to input some of this information at every transaction. The current system requires the user to always input the CC expiration date, for instance. So that's hashed. The remaining sensitive data is encrypted.

**anduril462** · 05-05-2011

Originally Posted by Subsonics

For anything vulnerable to dictionary attacks such as passwords it is feasible by hashing your "words.txt" file that you use for the dictionary attack, hence the salt that was mentioned earlier. I don't see how a credit card number can be exposed by a dictionary attack though.

Maybe I wasn't clear.

The dictionary attack comment I made in post #14 was simply stating that, out of the (assumed) 77 million accounts, odds are some of them had easy dictionary passwords, thus, somebody could relatively easily find a user name and password combo. I doubt that gives direct access to any CC info, but who knows. I have no idea what all data they got and how any of it was salted or encrypted, etc. Suffice to say that having valid logins and passwords certainly compromises a system that stores credit card info on it. I don't know how probable it is, but it's certainly possible.

The hashing comment I made in post 19, that you quoted, was in response to Mario F's loose usage of "hash" in post 15. A loose usage he confirmed in post 21.

Thread: One wall falls, another rises in it's place

Thread Tools

Search Thread

Display

Similar Threads

FscanF Program falls over

The wall behind is showing over the wall in front. (Glut)

Jet Li falls on hard times?

temperature rises

when does niagara falls open ?