Tag Info

New answers tagged

2

How good are your programming skills? It would not be too difficult to write a program or script that loops over all possible salt strings, take your password "123"and try sha1($pass.$salt) and sha1($salt.$pass). If the hash that comes out matches the one in the database, then you've found your salt. One possible problem is knowing exactly which hash ...


1

MD5 is known to be generally faster than SHA256. You can confirm that on this page, for example. OpenSSL for example has a built-in benchmark suit, so you can compare yourself by running: $ openssl speed md5 $ openssl speed sha256 But of course, the hardware and software you use to compare them can make difference. You can see the results this user got ...


1

It depends on the hardware and software you are running. Below are comparison results between MD5 and SHA using the openssl library on my computer. But different implementations that take into account hardware acceleration will give different results. Modern CPUs have hardware acceleration for hash functions. GPUs will have better results and specialised ...


-1

Hashes are one-way functions, which essentially means, they were constructed to make practically impossible to reconstruct their input from their output. However, there are some narrow possibilities to reconstruct the original value: If you can somehow narrow the possible values, you can hash them one by one and compare to your desired output. For ...


2

There are actually two kinds of KDFs. One kind is designed to derive a key from high-entropy input (like another key); this can be done with a fast keyed hash like HMAC. The other kind takes a password as input. Passwords are low-entropy; they're not inherently very hard to brute-force. A good password hash thus has to be slow. In your question, you said ...


2

Since PBKDF2 could be use to generate as much bytes as you want/need, you can of course use it for both master password hashing and key generation. You don't even need to use different salt, just generate a n bytes hash, then generate n+m bytes, discard the first n bytes and use the other m bytes as key.


1

See this for an introduction on password hashing. That your method ("sha1(password + md5(login))") may be guessed by the attacker is not a problem. Well, it is an indirect problem. Ideally, a "secret algorithm" would protect you even if the said secret algorithm was abysmally weak, because the attacker would still do not know the ends or tails of what you ...


0

The security in a hash function is not that the mechanism is unknown - it is that the hash function has been proven over time to be secure. For example, uniform distribution over the keyspace, and has cryptographic properties such as collision resistance, preimage resistance and second preimage resistance. For password hashing, collision resistance and ...


0

You've misunderstood the reason why you shouldn't attempt to roll your own password hashing procedure: It's not that knowing the details of the algorythm can lead to someone can understand the mechanism behind it (in fact, it is expected: see Kerechoff's principle), it's that writing good crypto is hard. As an example, the function you proposed is weak: ...


0

Hashing of the password prior to transmission happens for some authentication protocols, most notably the WAP/WPA2 PSK four way handshake. In this scenario, the WPA protocol needs to prevent against a masquerade attack, such that a rogue AP cannot obtain the plaintext password when prompting clients for authentication. In this protocol, an attacker who ...


0

There are no theoretical benefits from hashing client-side and server-side to hashing twice server-side ; unless the connection between the client and server cannot be trusted. However in practice, I have seen multiple instances where plain-text passwords ended-up in logs (mostly in error logs). In this particular scenario it has a clear advantage. I ...


0

I think 80 bits is just a reference to the general lower limit of what's considered computationally infeasible to brute force. From wiki: In 2002, distributed.net cracked a 64-bit key in 4 years, 9 months, and 23 days. As of October 12, 2011, distributed.net estimates that cracking a 72-bit key using current hardware will take about 45,579 days ...


0

On Windows, there is a small root certificate scanning tool called RCC that you can use to detect if your root store has been compromised. This won't prevent a malicious certificate insertion, but for detection purposes it is fine. http://www.wilderssecurity.com/threads/rcc-check-your-systems-trusted-root-certificate-store.373819/


2

The "keyed MD5" described in RFC 1828 can be summarized as follows: for key K and data D, the MAC value is MD5(K||D||K) (in the RFC, K is first padded to a length multiple of 512 bits, but it does not substantially change things here). To my knowledge, there is no known weakness to that construction, but there is not much security analysis either. HMAC has ...


1

I'll step by step and then overall crypto system, seems most logical to me. Generate a new AES 256bit/CBC/PKCS7 Master Key (Km) Generate a new 128bit IV (strong PRNG) CBC is fine here as there isn't any sort of oracle the attacker would have access to and bit-flipping attacks are ruled out by the tag. Random IV is correct, 256 bits is more than ...


3

What you presented is not an encryption scheme, you just took a number and modded it by 7. This can not be an encryption scheme because there is more than one "message" which will produce the same "cipher text", for example: the message 22 produces the cipher text 22 % 7 = 1 the message 29 produces the same cipher text 29 % 7 = 1 the message 36 produces ...


0

Here is the answer to related question which should resolve all of your confusion: How to securely hash passwords? EDIT: To question 1. As was said by other answerers, you can't prevent brute force by salting your passwords. Other techniques exists for this task, usually it's throttling of some kind and limiting number of attempts. Gradual throttling with ...


7

Simple version : Salts don't stop brute force attacks against a single user's password. What they stop is is you being able to do a brute force attack against all of the users' passwords at the same time.


21

From your initial understandings: A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate. As ...


0

Your first point is easily answer. There is nothing that prevents that. Salt are not a mean to avoid brute-force attacks anyway. Your second and third point are more relevant. Salts are here to avoid having one rainbow table to rule them all. That is to say, for each user, you have a different salt. This means that if you want to attack multiple users, you ...


2

Salt don't help against brute force attacks, as the attacker is firing all passwords known to men, he will eventually get lucky and guess it right. Salts become helpful when the stored passwords have been stolen, to find the password that belongs to the hash (I wouldn't use MD5) you can take a random password, hash it, and check it against the hash you ...


1

That does indeed severely compromise security. There are no ifs, ands, or buts about it: if you have CAs that your computer trusts but are not the real ones, anything that relies on the OS store won't work (I believe Firefox has its own certificate store, but then that has to stay secure). See: the Superfish debacle, where the problem was that a hardware ...


1

Hashes should not be stacked; rather, the result of multiple hashes should be XORed together. Such a primitive (that XORs together multiple believed-strong hash functions) can be used in the loop of PBKDF or similar to achieve results much superior to stacking hash functions. What has to be factored in to the cost-benefit analysis is that such a protocol ...


12

I was asked to make my comment an answer, so here goes. Basically, I said that the likes of bcrypt, scrypt and pbkdf2 are not hashes themselves, but are KDF's (key derivation functions). KDF's are built upon HMAC algorithms, which in turn are built upon one-way hashing algorithms like SHA-256 to generate the message digest values. There is already ...


10

To copy my answer to a similar question on progs.SE: the problem with hash1(hash2(hash3(...hashn(pass+salt)+salt)+salt)...)+salt) is that this is only as strong as the weakest hash function in the chain. for example if hashn (the innermost hash) gives a collision the entire hash chain will give a collision (irrespective of what other hashes ...


26

When trying to hash passwords, the attacker can always use the same kind of hardware as the defender. What the attacker tries is to do better, by using specialized hardware which will allow him to hash N potential passwords for less total cost than if he were using the defender's hardware. The total cost includes the cost of buying the hardware, the cost of ...


2

Mixing hashes usually results in the security of the weakest hash in the chain namely: First preimage resistance Second preimage resistance Collision resistance Rather than mixing hashes, the CPU power is usually best directed at hashing with more bytes. In other words, if hashing with two algorithms requires N Joules of work and results in less ...


6

Using different hash algorithms will not give you more entropy, rather less. I guess that you have heard the expression «The security is not stronger than the weakest point», same applies here also. The entropy of this will not be more than the weakest algorithm gives. But hashing the the password with same algorith multiple times will give you more ...


1

If you change from: myhash = Hash1(Hash2(Hash3(password ^ salt))) ...to... myhash = Hash1(password + salt + Hash2(password + salt + Hash3(password ^ salt))) ...then you may have reduced the risk of a collision of Hash1...


2

Edit: I saw that you found your answer, but I'll add it here for completeness sake. (And I already had this written down). Hashcat doesn't guess the # of rounds, and the amount of rounds specified in your /etc/login.defs isn't properly applied. I took an example from my Linux box: ...


10

Assuming the router follows the glibc standard for password hashes, the second field ($1$$N76hdwGfg11g0KdKbtyh21) is the password, and is encoded as follows: $1$: iterated MD5 hash $: No salt N76hdwGfg11g0KdKbtyh21: the hashed password, in base64 encoding. In hex encoding, it would be 37bea177019f835d60d0a74a6edca1db


11

The most common format for hashes on Unix-like systems has the form $ALG$SALT$OUTPUT where ALG is a small number identifying the algorithm, SALT is a salt for the hash and OUTPUT is the output of the hash function. SALT and OUTPUT are encoded in base64. Algorithm 1 is “MD5 crypt”, a construct based on iterating the MD5 hash function. This algorithm was not ...


4

You are essentially correct in your last paragraph: Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it. Though, as mentioned in comments, and in various places ...


3

q1) Correct. Every message needs to be sent with its own signature. But if lots of information has to be sent this way, it is not very efficient because public key cryptography is rather slow. Usually the two parties would rather use a protocol allowing to share a secret, then use symmetric-key authentication, like a message authentication code (MAC). q2) ...


0

The first thing I would do is run any proposed solution past your PCI auditor to ensure your not going to deploy anything which will cause issues and put the company outside of PCI compliance. It sounds like all you need is to have the card numbers tokenized in such a way that you will always get the same token given the same card number and there is no ...


1

Hashes are not compression schemes. The password you are looking for is not stored in the hash, though it is theoretically possible that somebody has a dictionary that maps it to its original content. Given knowledge of the scheme, MD4(MD4(($pass)).(strtolower($username))) You can guess it. MD4 is decently fast to calculate, so if you have $username, ...


4

Details matter. As @Ricky points out, showing truncated HMAC values won't help the attacker finding the secret key, compared to a similar situation where the HMAC values would not be truncated. This makes sense: the truncation only removes information. However, the attacker is not ultimately after the secret key. What the attacker really wants is to make ...


2

Yes. ​ Yes. B interacts with A and the challenger as follows: B forwards all queries from A to the challenger, and gives the same output as A. For each response from the challenger, B truncates the response and sends the truncated response to A. A's view in that interaction is identical to A's view in the interaction for your scenario with the same key, ...


5

Rfc2898DeriveBytes implements the standard algorithm known as PBKDF2 and defined in RFC 2898 (hence the name). That algorithm uses a configurable underlying pseudorandom function, which is usually HMAC, and HMAC itself relies on a configurable underlying hash function, usually SHA-1. While all of this is configurable, a given implementation might not be as ...


2

is there any way for me to be able to get the full hash? No. You didn't name your hash function. So I'm assuming, your talking about a regular cryptographic hash function, like SHA-256 for example. In your regular cryptographic hash you want what is called the "Avalaunch Effect". It means that if even one bit of the input is flipped, added or removed, ...



Top 50 recent answers are included