DRM and Password Authorization
We log in online and are accustomed to being refused service if we supply an incorrect username/password combination.
We persecute "plain-text offenders" and rightly expect to benefit from comparing a hash fingerprint of the credential presented online to a list of hash fingerprints, each paired with a username. Even better if the username is hashed as well.
The knowledge gained from online handshakes can benefit us in digital rights management.
It has long been the case that we could obfuscate a password literal in source code by compiling it into object code. However, decompilers provide assembler code that can reconstruct the source code without descriptive variable names and make string values stand out.
Now, we can construct a creative solution. We can designate a username/password combination to COMPILE SOURCE UNIQUELY FOR EACH USER. To hide it in the object code, we hash the username and password with a published hash algorithm and use the hash-fingerprint literal instead of the plain text.
The reason for multiple hashing is not that it makes the hash more secure. It does not. One iteration of a hash is completely irreversible. The reason for multiple iterations is that the time needed to repeat the hashing MULTIPLIES the TIME needed to try unauthorized password attempts.
Since miscreants forever compile rainbow tables, we salt hashes as a matter of procedure.
I welcome anyone to contact me, if the idea of "encrypt uniquely per user" can be improved. In the case of this entry I have suggested a unique compile instead of encryption. I understand that this hinders scalability.
@dictionarian on Twitter/X
Comments
Post a Comment