Tag Info

New answers tagged

2

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 ...


0

As @kjetil-limkjær points out, Powershell version 4 and up includes the Get-FileHash cmdlet. powershell get-filehash -algorithm sha1 <file_to_check> Use doskey to make a persistent alias that's easier to remember. doskey sha256sum=powershell get-filehash -algorithm sha256 "$1" doskey sha1sum=powershell get-filehash -algorithm sha1 "$1" doskey ...


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.


0

I am surprised that people haven't noted that you can and should encrypt the verifier in the db. Typically with large firms the databases are segregated infrastructure. The backup regime of the database servers is also usually deliberately different than the host level backups of the applications servers and web infrastructure. Db backups are usually offsite ...


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 | ...


0

The hexadecimal part is 128 bits long, which could be a MD5 hash, iterated MD5, some other hash truncated, or something completely different. We just don't have enough information to conclude. The ":lreto" part looks like an username, not a salt. The right way to go about knowing how this password was stored, short of reverse engineering the program ...


0

You would be limiting yourself to the range of keys the hash may output, which is likely less than you would generate using a password manager. SHA-256 has a range of 0-9 and A-F with only 64 bytes of output, turning pXieG)MF8YRI`{H+/wCw(i/uE*ja#MFl^OQZq=oj!@R6miK_E#RffzZ9C^9}F~KYN;H>{W{7"$x.,7cK4T&9czC4Sv=.uw5\g{fD into ...


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 ...


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 ...


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 ...


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 ...


0

It seems just as safe as any other scheme, however since your using the service url as a starting point you have a possible easy to guess password (part of it is now public knowledge). Now if you would use a different word you can use this trick to get your salting from the name (factorise the ascii values of the name for example). and hash the key word n ...


-1

There's no reason why this construction should be insecure except for standard chosen-plain and ciphertext attacks. To prevent those you still need an authentication mechanism. (like AES-GCM or Poly-1305). As practical construction I'd suggest you using an offset. Hence you would use the first few bits from the PBKDF to derive a key for authentication and ...


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 ...


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 ...


0

How is the hash derived, and how is it secure? The hash is derived using a cryptogaphic hash function. Hash function usually have the following three properties: Preimage resistance: From a given hash you can't (easily) find out the corresponding input to the function 2nd Preimage resistance: From a given hash and a given input you can't (easily) ...


0

Here's a link to a related question. The general answer is that before the message is signed with Alice's private key, it will be hashed with a hash function of Alice's choice. RSA is not tied to any specific hash function. Alice will include in the header of the message which combination of hash function + signing algorithm she used. For example: in TLS ...


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 ...


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).


0

In fact although you might be said to be performing the hash for lookup performance, it is being done to be PCI compliant. There are two ways of looking at this. Do x, it is the right thing to do. Do x, or we'll get caught not doing it. Doing x to prevent cracking does not really come into it, since there are only about 5 numbers to guess in some cases. ...


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 ...


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 ...


1

If you know how the salt is used when hashing the clear text phrase this only makes it easier to brute force. The number of possibilities you have to check will be going dramatically down, since you only have to check for the phrase without the salt. Still if it is a long phrase with many different characters it will take a lot of time.


1

Hash functions are designed to go only one way. If you have a password, you can easily turn it into a hash, but if you have the hash, the only way to get the original password back is by brute force, trying all possible passwords to find one that would generate the hash that you have. Assuming the salt is very long, not knowing the salt would make it nearly ...


1

Tracking down the links referenced in the answers, I think it would be safe. Out of an abundance of caution, I will exclude the private key from the list of md5sum values I allow to be stored on computers connected to the Internet. I will then use the signatures generated for the same binary to confirm the excluded private keys are identical. Even if ...


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 ...


0

Although it is only the collision resistance property of MD5 that has so far been compromised, I would not use MD5 for any cryptographic purposes even though in your case an attacker would need to compromise the pre-image resistance. Use a secure algorithm such as SHA-256.


0

Does the visual fingerprint uniquely identify a server's key? No; the "visual host key" algorithm does not preserve enough information to give each key a 100%-guaranteed-unique image. But neither does a more traditional fingerprint. ECDSA keys like yours have 256 bits. RSA keys have 2048. But if you count the hex digits in your image, you come up with ...


1

Looking at your comment on @zedman9991's answer; if you want to check that the servers' filesystems are identical, why not generate one hash for the whole filesystem, rather than one hash per file? This will likely fail on two different severs since operating systems generate files like candy, timestamps / MAC addresses will differ, etc, so it might be ...


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.


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 ...


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 ...


-1

It is good practice to hash on the client side, then salt the password and hash again on the server side. This is an extra layer of protection against man in the middle attacks. SSL is the first layer however Snowden's revelations made it clear that SSL can be compromised by organisations such as the NSA with relative ease.


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 ...


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, ...


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, ...


0

applying the same hash function several times makes the hashing process more computationally expensive. The benefit of this is that when other means of cracking the password hash fail (guessing, dictionary attacks, rainbow tables, etc.), and the attacker is forced into brute-force techniques, it takes them longer to try each password, simply because they ...


1

Ok, so I found some resources that are helping me to answer my question. There is a module that allows you to use PBKDF2 with either SHA1, SHA256 or SHA 512. This is probably the best solution for most situations. (See: https://github.com/hamano/openldap-pbkdf2 ) Alternatively, you can use the local Unix/Linux crypt facility, and configure OpenLDAP to salt ...


1

I have faced a similar problem, for which I implemented the following mitigation. I would greatly appreciate input as I do not claim that this is necessarily an excellent solution. TL; DR Store IDs as HMAC(ID, master-key) and each user's password is used to derive a per-user key to encrypt master-key. Adversary capabilities / limitations It protects ...


2

No, there is no overwhelming need to hash password reset tokens, as long as they are time-limited and single-use. There's some benefit to hashing reset tokens, but the benefit is less than with passwords, so I wouldn't consider hashing of reset tokens absolutely necessary. Typically, password reset tokens are time-limited. For instance, they might be good ...


10

Yes, you should hash password reset tokens, exactly for the reasons you mentioned. But no, it's not quite as bad as unhashed passwords, because 1) reset tokens expire and not every user has an active one, and 2) users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change ...



Top 50 recent answers are included