Tag Info

Hot answers tagged

17

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the ...


16

SHA-1 and MD5 are broken in the sense that they are vulnerable to collision attacks. That is, it has become (or, for SHA-1, will soon become) realistic to find two strings that have the same hash. As explained here, collision attacks do not directly affect passwords or file integrity because those fall under the preimage and second preimage case, ...


14

As @cpast says, the main problem of a single SHA-256 is that it is way too fast. An attacker with an off-the-shelf gaming GPU can try passwords at a rate that is counted in billions per second (American billions, but that's still a lot). Another problem is that there is potential for combining things improperly. SHA-256 is a hash function: it takes one ...


11

First things first, you should use a password manager to solve the problem that you're trying to solve. A 256-bit hash like SHA-256 outputs to 32 bytes of hexadecimal characters. This means that for every character, there are 16 possible choices, 0-9 and a-f. Using a password manager like KeePass, you can generate a 32-digit passphrase using 64 or more ...


10

For MD5, no one who is both reputable and competent is using it in a context where collision-resistance is important. For SHA-1, it's being phased out; the SHA-1 break was not practical when it was released, and only now is it becoming important to think about phasing it out where collision-resistance is needed. In fact, it is being phased out; for instance, ...


9

By using PBKDF2 that way, what you are really doing is turning PBKDF2 into a stream cipher. The three main problems with this idea are: Use of PBKDF2 as a stream cipher has not been thoroughly investigated. It may be fine. Or not. Security properties of PBKDF2 have been analyzed for mostly short outputs only, and then, only as a KDF. If you reuse the same ...


7

Your main problem can be summed up as: where's the SSL ? Any eavesdropper, observing the exchanges, will obtain enough information to run an offline dictionary attack: the attacker will be able to "try passwords" by recomputing the relevant hash values and see if they match that which was observed. This is "offline" because the attacker can do all of this ...


6

Bcrypt is run many times to intentionally slow it down. Perhaps you need to adjust the number of rounds of bcrypt you are running? This answer has some information on it. While what you propose may work, I can't say that implementing a variant of standard password handling is a good idea. While I have specific concerns, such as the SHA hash staying in the ...


6

sha256 is not designed to hash passwords. To hash passwords, you should prefer to use hash functions created for this usage. You will find all required information below in another question addressing a similar request: Most secure password hash algorithm(s)?. In the above mentioned question, you will learn why general purpose hash functions like sha256 do ...


5

My question to you is: What's the advantage? Even before any analysis at crypto level, your system falls down in the event of any breach. Say your WordPress system was hacked - you would want to change the password for this system to be on the safe side. So sha-256(Wordpress+MasterPassword) becomes sha-256(Wordpress+NewMasterPassword). This means you now ...


5

MD5 and SHA-1 are fast and may be supported in hardware, in contrast to newer, more secure hashes (though Bitcoin probably changed this with its use of SHA-2 by giving rise to mining chips that compute partial SHA-2 collisions). MD5 collisions are feasible and preimage attack advances have been made, but there is no publicly known SHA-1 collision for the ...


3

You are doing it wrong, and thinking it wrong. The problem with password hashing is not, and never has been, about collisions. The main problems with password hashing are speed (hash functions are too fast) and parallelism (a hash function is always the same as itself). There is a lot of theory on password hashing. As an introduction, read this answer. The ...


2

In some cases it might actually compromise the security of it. http://www.di.ens.fr/~fouque/pub/crypto07b.pdf HMAC-MD5 has a key recovery attack in the upper end of achievable but impractical, although attacks only get better over time.


2

You can use the MD5 cryptography hash without any serious concern but why not consider using the public key to confirm the private key in question. You could have the partner sign a sample binary and use the public key to confirm the signature and thereby confirm the private key. If you want to work outside the signing infrastructure you could use a ...


2

Asymmetric keys are only really valuable if one of them needs to be made public (though "public" can mean different things in different contexts). If you both generate and verify codes in private, than you can just use a private secret as part of an HMAC with a reasonable hashing algorithm. If space is a premium, you can even get away with using the ...


2

Using symmetric or asymmetric encryption in this case really depends on the use case and not on the security aspects. How is the code generated? can the code requester have a common secret between himself and the code generator? If they do you can use HMAC to verify the sender and the integrity. If not, you can use asymmetric encryption to utilize signing of ...


2

Does it make sense to use stateless JWT (without persistent storage) over plain SHA256? What you're essentially doing with "plain SHA256" is signing the data and sending the data + signature separately. JWT encodes both the signature and the data together, but in both cases you're basically signing the data sending the signature + data. In essence ...


2

The depicted design would entirely undermine the security of bcrypt. Your design could be simplified by simply eliminating the bcrypt part of the flow and rely only on the SHA hash. That simplification would not change the security of the design significantly, it would still be as insecure as simply applying a SHA hash. Using a SHA hash with a salt would ...


2

The risk here is that if an attacker manages to extract the SHA'd passwords from the database, then they can run a password guessing attack at a relatively fast speed. You should at least salt these password, but then you're increasing complexity which is generally at odds with security. A good secure system should be as simple as possible to make it so. I ...


2

Your protocol is not safe by any means! Example for MitM: A sends random nonce G1 to B C intercepts and sends nonce G1c to B B sends back hash_k(G1c) and random nonce G2 C intercepts and sends hash_k(G1) and nonce G2c to A A verifies hash_k(G1) (is OK), then sends back hash_k(G1 | G2c) C intercepts and sends back hash_k(G1c | G2) B verifies and a ...


2

I think you're confused because of a misunderstanding between encrypting and hashing. I'll try to clarify by quoting your original post. "When you view the configuration of the appliance it shows the key as a cipher text (imagine perhaps the idea is stop people shoulder surfing the key of the appliance). So the plain text key I entered in the appliance ...


1

No, you cannot use XOR as you would not be able to distinguish the order of the values underlying the hash tree: H(H(x) ⊕ H(y)) ≡ H(H(y) ⊕ H(x)). Furthermore you can create hashes over all zeros by inputting identical values: H(H(x) ⊕ H(x)) ≡ H(H(y) ⊕ H(y)). So you cannot use this for a generic Merkle tree.


1

The hash was created by Gravatar, not Disqus and it appears that Gravatar is still using MD5 to create user lookup IDs; meaning the intent of this implementation is to make it easy to create, store and lookup users, not hide who the user is. Also appears that Disqus still supports Gravatar; meaning MD5 is still the hash being used.


1

If you care about the security of someone's password, you should move away from PBDKF2, and at least to BCrypt. Look at the state of the art in cracking hardware. For BCrypt cracking in hardware, look at High-Speed Implementation of bcrypt Password Search using Special-Purpose Hardware. | Algorithm | hashes/sec | hashes/sec/Watt | ...


1

No, hashing a password does not increase your security. The security of your password is based on its randomness and length. Hash functions generate a "representation" of a given value in a specific format. The result might look random, but it is following a set of rules, the exact opposite in of randomness. This means that such a password is easier to ...


1

I wouldn't do what you are suggesting. It's too easy to guess the Website info ("Wordpress" in your example) and the salt is presumably public. You would do better hashing MasterPassword+Website where MasterPassword is a well-chosen, secure, random string. You can use the same master password for all of your sites. Even if the password for a site gets ...


1

Yes. Because of known-plaintext-attacks, a adversiary that can find out the plaintext, could use that to find out the hash to decrypt ciphertexts that the adversiary does not have the plaintext to. AES is specifically built to prevent a attacker from finding out the key, even if he knows both the plaintext and ciphertext. If you want to gain performance ...


1

You don't use a hash function to encrypt things. You use an encryption algorithm. You don't use an encryption algorithm to sign things. You use a signature algorithm. The text you quote uses to traditional explanation of signatures as "encryption with a private key", which is a very confusing way of stating things, and works only for a specific signature ...


1

No. Stick to known protocols such as TLS, Kerberos, SSH & IPSec for key exchanges. Try researching Diffie-Hellman key exchanges and ECDH (Elliptical Curve Diffie-Hellman, the new method of key exchanges like your example).


1

I'll answer in order: almost certainly yes, asymmetric signatures in general take more space than the symmetric counterparts - RSA requires a certain amount of padding and a minimum key size to be secure; if you use a HMAC the minimum requirements for a secure HMAC - a hash based Message Authentication Code or keyed hash - would be about 64 bits / 8 bytes ...



Only top voted, non community-wiki answers of a minimum length are eligible