Mike, see all the times you forget your password, and they let you reset your password instead of sending it to you? That’s because it’s stored as a hash, and they don’t have a clue what your password is. That’s why using the same password for many sites (trusted) isn’t a big deal because they can’t easily figure out what your password is.
Encrypting is a totally different technique, such as encrypting a database, it’s not turning all the data to hashes
Function cipherHex(key as string, dataHex as string) as string
// - encrypts | decrypts a 16-byte hex-encoded data string using provided key; returns a 16-byte hex data string
dim dataSeed as new memoryblock(16)
dim dataPlainText as new memoryblock(16)
dim dataOutput as new memoryblock(16)
dim indexLoop as int64
dataPlainText = decodehex(dataHex)
dataSeed = crypto.pbkdf2(crypto.hmac(crypto.sha256(key), key, crypto.algorithm.sha256), key, 3, 16, crypto.algorithm.sha512) // - generate hash based off key to use as a cipher pad
for indexLoop = 0 to 15 step 8
dataOutput.uint64value(indexLoop) = dataSeed.uint64value(indexLoop) xor dataPlainText.uint64value(indexLoop)
next indexLoop
return lowercase(encodehex(dataOutput.stringvalue(0, dataOutput.size), false))
End Function
I have, however, made a non-standard (keep away from DIY cipher engines when dealing with important information) cipher|decipher engine to use in reference to class I made to generate a hardware-based token key. It basically uses the hash from a password entered (using crypto) to act as a XOR pad (much like one-time pads do, or streaming ciphers do with pseudo-random number generators). This likely isn’t very secure, but it was quick to implement and make for something as trivial as what I’m doing with it.
Right, so when you type your password into a website, a hash is generated and compared to the hash they have stored on their database from when you first enrolled?
Then it wouldn’t be an overly trusted site. If the programmer doesn’t know how to salt, re-hash, encrypt at nassium then he probably shouldn’t be working for the company.
Security of a password isn’t just susceptible to being breached at the remote end. Somebody could intercept it during communication, or it could be keylogged at the user’s PC (just to name a few scenarios). I don’t think Kem was implying that the hash methods used by a developer are the weakest link.
But how will you know they screwed it up until after the fact? LinkedIn stored unsalted MD5 hashes. Could you have predicted that one? Could you have predicted that Sony did absolutely no protection at all?
Don’t reuse passwords. You don’t know how well the receiving end is protecting them. If something is wrong, you severely limit the damage.
At the absolute minimum, do not use the same email password you use for anything else. If your e-mail is compromised, just about anything else can be too.
[quote=168657:@Lars van Doll]To decrypt / reverse hashes you can use http://hashtoolkit.com/
It supports md5 and sha1 hashes.[/quote]
They are very clever, but if you start with the notion that hashes can’t be “decrypted”, what they did is transparent.
Do this: Start with Xojo and generate an MD5 hash on some long, obscure text, then go to that site and attempt to “reverse” it. Your attempt will most likely fail.
Now go to the page on that site that generates hashes and generate the hash for the same text. Then go and try to “decrypt” that text again. Ta DA! Suddenly it can do it.