Is there a way to decrypt CRC-96 encrypted string? I am testing a web application which stores the password in the database in CRC-96 encrypted format.
Asked
Active
Viewed 3,188 times
-1
-
2... you store user passwords as CRC hashes!? – SEJPM Apr 24 '16 at 15:43
-
No, I'm not. Just got a CRC-96 enc password from db table. – user2274486 Apr 24 '16 at 15:47
-
4Wat. Nothing you say makes any sense to me. Decoding is not decryption. And you can not (from no data) get the data that produced that checksum. And @SEJPM's good question has not been answered - if you get them like this, the DB stores them like this? That's horrible. Please do some reasearch, get the difference between hashing, checksums, encryption and encoding and try to mend the question. – Tobi Nary Apr 24 '16 at 16:21
-
@Daisetsu that's where the "research" part of questions comes in handy - here are many answers explaining this very good. And while we can guess what OP is trying to ask with wrong vocabulary, the question is not useful to future readers as-is. Also, feel free to discuss such things in the [Sec.SE CVR room in chat](https://chat.stackexchange.com/rooms/37754/sec-se-cvr) next time; there is [a meta about this](http://meta.security.stackexchange.com/q/2288/92273) as well. Additionally, I do not see a downvote brigade. – Tobi Nary Apr 24 '16 at 18:19
1 Answers
4
While I'm not familiar with CRC-96(ZIP) I'm assuming it is a longer version of CRC-32, but similar in it's function and implementation, so my answer is predicated on that.
CRC is essentially a one-way function. Like other hashes this is a lossy operation, resulting in an output of a pre-determined length. You could put in the word 'cat', or the entire contents of a novel, and the length of the CRC for each of those would be the same.
Due to this, there's no way to simply reverse the function. That doesn't mean it's totally secure though.
If the function produces a short result, it wouldn't be too difficult to brute force all the possible inputs until you found the password which produces that result, or a collision.
In non-cryptographically secure hash algorithms (I believe this to be the case for CRC-96(ZIP)), it's not difficult to find a collision. Then I could just take that collision, submit it to the application which calcualtes the CRC of it, then compares it to the database value, and you are then compromised.
Long story short, is you can't 'decode' a CRC, but you can find a collision, or the original through brute force.
-
This is just for CRC (I'm guessing 32 bits) but is likely relevant https://blog.affien.com/archives/2005/07/15/reversing-crc/ – Neil Smithline Apr 24 '16 at 19:31