I am working on a Desktop Application using VB.net with an existing database. Including the user's username and password, I want to do the login window using the existing password but it was hashed password. May I know what hash algorithm use in this data X8NUoMVWb/w6D4QdmumxoQ==?
You can make an educated guess simply by looking at the length of the hash, as generally there's only a handful of popular hashing algorithms used for passwords, all with their own distinct output lengths:
Hash
Output length (bytes)
Output length (bits)
MD5
16
128
SHA-1
24
160
SHA-2 (SHA256)
32
256
SHA-2 (SHA512)
64
512
You can never know for sure because while different hashing algorithms have different output sizes, the output can always be truncated (or padded with random bytes).
That said, X8NUoMVWb/w6D4QdmumxoQ== is a Base64-encoded binary value which decodes to a 16-byte value. 16 bytes is 128 bits - it's very likely this is an MD5 hash value.
The 16 bytes convert to Base 16 (hexadecimal) are 5FC354A0C5566FFC3A0F841D9AE9B1A1.
This MD5 hash doesn't appear in any freely available leaked password databases or hash-reverse services I tried.
Note that systems like bcrypt generate an output string which is not just a hash-value, but actually a data structure containing the hash and other data. In bcrypt's case the string always starts with $2 which will never appear in a Base16 or Base64-encoded string.
Related
Since I want to scale up a simple website but I just need a simple encryption done through environment variables rather than setting up a Redis to hold the key.
I'm looking at this Converting Secret Key into a String and Vice Versa to do the retrieval.
I know I can export the string but I was wondering if any arbitrary bytes can be used so long as it meets the length requirement.
An AES key is a sequence of 16, 24, or 32 bytes chosen by a cryptographically secure random number generator. There are no checks other than the length.
Is it safe to hash extremely complicated password (longer than 25 chars, any ascii chars even binary) with SHA1 ?
Actually, the password represent a tokenID but I don't want to store it like this in the database, i prefer to hash it for more security.
The password (token) is valid only for 14 Days and I need to hash it the most faster as possible (so no way to use something like bcrypt)
What must be the ideal length of the Password (token) ?
In the general case, no. "Complicated" it may be, but cryptographically random it probably is not.
A bare minimum would be applying an RFC2104 HMAC with a secret key (pepper); however, a more appropriate alternative that can, if you absolutely insist, still be quite fast would be to use PBKDF2-HMAC-SHA-256 and ignore all rules of security regarding a sufficiently high iteration count, i.e. choose an iteration count of 10, instead of 10,000.
For password/token hashing, of course, never request more bytes of PBKDF2 output than the native hash function provides - 20 for SHA-1, 32 for SHA-256, 64 for SHA-512.
I have several example implementations of PBKDF2 at my Github repository that may help, and there are others in other languages, of course.
Use a cryptographically random per-password (per-token) salt.
Lets say I split a 1G file to 1024 chunks of 1Mb in browser, get an SHA1 of every chunk and save this hash temporary. Finally after hashing all chunks, do an SHA1 of all previous collected SHA1-hashes (do an hash of hashes). Then send this "final"-hash to my server.
Would this hash be secure to identify my file on the server? (Assuming we have an secure connection and sha1 was collision free)
Is it an bad idea to do an hash of multiple hashes?
I guess your objective is to check integrity of the uploaded file comparing a chekcsum calculated in client side and in server side after completion. Then hashing each chunk, combine them and hashing the result should be enough.
//pseudocode
SHA1.digest (
SHA1.digest(chunk 1) + SHA1.digest(chunk 2) + ... + SHA1.digest(chunk n))
But note you can perform an incremental SHA1 hash on the complete file adding each chunk to the calculation. In this way the result is the same that hashing the complete file in one step and you do not need to combine temporal data
SHA1.update(chunk 1)
SHA1.update(chunk 2)
...
SHA1.update(chunk n)
SHA1.digest ()
Consider also to move to sha256 as shown in the comments, but probably for this purpose SHA1 would be adequate
This should work. Assuming SHA-1 is collision free, for two different files at least one of this hashes differ from each other. So the "final" hashes will also differ.
In general, hashing hashes does not improve security. If you want more security use SHA-256.
I am writing a string of about 120 characters to a 2D barcode. Along with other text, the string contains a unique ticket number. I want to ensure that someone doesn't generate counterfeit tickets by reading the 2D barcode and generation their own barcoded tickets.
I would like to hash the string and append the hash value to what gets embedded in the barcode. That way I can compare the two on reading and see if the data had been tampered with. I have seen several hash function that return 64 bytes and up but the more characters you embed in a 2D barcode the bigger the barcode image becomes. I would like an algorithm that returns a fairly small value. It would also be nice if I could provide the function my own key. Collision is not that big of a deal. This isn't any kind of national security application.
Any suggestions?
Use any standard hash function. Take the 120-character string; append your own secret value; feed it into SHA-1 or MD5 or whatever hash function you have handy or feel like implementing; then just take the first however-many bits you want and use that as your value. (If you need ASCII characters, then I suggest that you take groups of 6 bits and use a base-64 encoding.)
If the hash you're using is any good (as, e.g., MD5 and SHA-1 are; MD5 shouldn't be used for serious cryptographic algorithms these days but it sounds like it's good enough for your needs) then any set of bits from it will be "good enough" in the sense that no other function producing that many bits will be much better.
(Warning: For serious cryptographic use, you should be a little more careful. Look at, e.g., http://en.wikipedia.org/wiki/HMAC for more information. From your description, I do not believe you need to worry about such things.)
I would like to create unique string columns (32 characters in length) from combination of columns with different data types in SQL Server 2005.
I have found out the solution elsewhere in StackOverflow
SELECT SUBSTRING(master.dbo.fn_varbintohexstr(HashBytes('MD5', 'HelloWorld')), 3, 32)
The answer thread is here
With HASBYTES you can create SHA1 hashes, that have 20 bytes, and you can create MD5 hashes, 16 bytes. There are various combination algorithms that can produce arbitrary length material by repeated hash operations, like the PRF of TLS (see RFC 2246).
This should be enough to get you started. You need to define what '32 characters' mean, since hash functions produce bytes not characters. Also, you need to internalize that no algorithm can possibly produce hashes of fixed length w/o collisions (guaranteed 'unique'). Although at 32 bytes length (assuming that by 'characters' you mean bytes) the theoretical collision probability of 50% is at 4x1038 hashed elements (see birthday problem), that assumes a perfect distribution for your 32 bytes output hash function, which you're not going to achieve.