Tag Info

New answers tagged

1

The thing that you are asking about is called hash collision. To make it extremely simple let's say your hash has 1 byte (=8 bits). This means that you can assign a distinct hash to at most 2^8 messages. If you had 2^8 + 1 (257) messages you would definitely experience a collision. Now let's fast forward to todays situation. MD5 for example has 128 bits. ...


2

Yes, it's possible because of the limited length, but it has a very little chance. Read a bit about hash collision, for example: http://preshing.com/20110504/hash-collision-probabilities/


4

It is most likely a sha384 hash. BTW the hashed string is in this case 123456781 I found this out using this tool: CrackStation


3

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption. bcrypt(cost, salt, input) state ...


0

Common practice is just to use any hash algorithm, such as SHA-2 on the client. For slightly more security, a slow hash can be used such as PBKDF2, bcrypt, or scrypt. A slow hash is a hash designed to require a great deal of computational power, making brute force attacks with lists of common password more diffucult. The actual security advantage of slow ...


3

Bcrypt is not reversible. You can use it client-side as well as server-side. The key is not static but rather dependent on the password, generated by the function call EksBlowfishSetup(cost, salt, input). The plaintext is known and public, its "OrpheanBeholderScryDoubt". If you wanted to retrieve the key, you would need to mount a known-plaintext attack on ...


1

Edited to add: It turns out that what I've written is correct, but it isn't an answer to the question that was asked. I apologize. Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for ...


8

This is extremely unsafe, to the point of being pointless: Your hash function is not a one-way function. One can instantly (with constant and low runtime) calculate an input producing any given hash if you allow arbitrary 4 character passwords as inputs by undoing the XOR with the initial hash value formed from the password length. With a little ingenuity, ...


6

32 bit hash function cannot be possibly safe for the purpose of password verification. Problem here is that it is "easy" to find a colliding password, that is, a password, that hashes to the "correct" hash value despite being different from the original password. On average it will take 2^31 password trials to get such collision, which is considered very ...


2

The reliable way to check this, I think, is to put yourself into attacker's position, dump hashes, and see if LM hashes show in those dumps. You can do this with variety of pwdump-like tools. I haven't done this in a while, but if memory serves, output file contains user name and id, along with LM and NTLM hashes. If LM hash isn't present, it will be ...


4

The term you're looking for is "hash rate", and a quick Google search indicates that a GPU-based password cracker can try on the order of 10^10 passwords per second when cracking MD5 hashes. Generating hashes is an example of an "embarrassingly parallel" process, so doubling the available computing resources will double your hash rate.


0

What Math has told you is correct if you assume uniqueness and equality. For example, from a = b + c, it follows that b = a - c. Why is that? Addition has an inverse function mapping a pair of integers to a unique integer again. If you think of + as a function with infix notation and two arguments. Think of - as the inverse of that function. Then you would ...


1

Short answer: No The constants are part of the algorithm. If you don't trust the constants, then don't trust the algorithm. It is worth looking at some examples. Merkle-Damgård hashes One constant that could be changed in such an algorithm is the IV. For security analysis, changing the IV is equivalent to prepending the data with one block of key ...


2

I'm not a security expert, but didn't the NSA get a bad reputation for intentionally choosing breakable constants for one of the NIST standards a while ago? It depends on your threat model I guess. If you're worried about the NSA, then maybe you should hire the best cryptographers in the world and have them find better constants. Otherwise, just go with ...


1

Funnily enough, all of your questions are answered by the same word: salt A salt is typically a large (128bit) random value. First, a unique salt is generated for each password. Now, instead of hashing the password and storing it, we append the salt to the password and then hash the result of that. Now, we store the salt and hash in the database. ...


1

It's a different scheme. Generally it is accepted that when using a password hashing algorithm, which is intended to be very slow, is acceptable. What KeePass is doing is very similar to what most hashing algorithms do, namely slowing down hash calculation. Their way is not a standard way. Most password hashing algorithms, such as PBKDF2, scrypt and bcrypt ...


1

Simply put, the purpose of the salt is to make hash different for the same password. hash('password') == hash('password') // same password, same hash hash('password'+salt#1) != hash('password'+salt#2) // avoid hash collision with salt Now let's take your approach and expand it. It is equivalent to: finalHash = ...


1

Your "salt" doesn't seem to provide any of the benefits that are the point of using a salt. Using your scheme, each password only produces a single output, so an attacker knowing your scheme (which you must assume they do) can easily produce a rainbow table of possible hashes to match against those in your database. A salt is supposed to prevent this, ...


3

True All members with the same password have the same hash, unless the hash has been salted with a random value. In fact the hash value for "password1" is always the same regardless of the web application


4

Yes, sort of. Ideally two values are stored. A unique salt, and a hash of the salt+password. A globally unique salt is generated and stored for each password. Again, sort of. First the salt for that user account is retrieved from the database, then the salt+password is hashed and compared to the hash value sotred in the database. No, because the salt ...


4

Short answer: don't do it. Salt should be used to provide some security against leaked hashed passwords, since the same password will have the same hash, when unsalted. If salt is predictable, there is no gain. Since you're not adding any entropy by doing that, there is no gain by doing that kind of thing. And since you're using a very small number of ...


16

Don't do it. Salts have to be unique, that's their only requirement. But your approach doesn't generate unique salts, but password-dependent ones. A per-db-unique salt helps when its long enough (256 bits), and you also hash in the username, but that still leaves issues. Having only 3 iterations of SHA256 is rather not the way password hashes should be, ...


8

No, due to reasons you have already stated: Don't design your own algorithms. You can achieve resistance from rainbow tables by using unique salts, no need to mess with the constants of your hashing algorithm. The algorithms have been subject to thorough cryptoanalysis by international experts, like for NIST SP800-90 Dual Ec Prng, its likely you won't have ...


29

No. The constants are part of what make the hash secure, and the constants in the specifications are what have been used in the cryptographic community's examinations of the hash functions that we currently believe are safe. It has been shown that intentionally badly chosen constants can break a hash function in subtle but exploitable ways, and coming up ...


2

There's too few information here. Not knowing the full challenge, it's very hard to suggest what they expected you to do. Maybe you were supposed to notice the encryption method and break it, perhaps the key was given somewhere else, you may even be expected to break or guess it (eg. if it was 1234). I suggest you wait for a summary of the challenge by ...


2

Unless it is an insecure cipher, you won't be able to know which algorithm was used. That's what confusion/diffusion is all about. From my experience with such challenges, I'd say you're missing something. Maybe there's a key somewhere, maybe you get your hands on some source code, etc.


2

Consider this: $ echo Hello | md5sum 09f7e02f1290be211da707a266f153b3 - $ echo -n Hello | md5sum 8b1a9953c4611296a827abf8c47804d7 - In the first case, you hash six bytes, for 'H', 'e', 'l', 'l', 'o' and a newline character (0x0A). In the second, you don't include the newline character, which mimics what OS X md5 utility does with the argument -s.


4

By default, echo leaves a trailing newline. So you need to do: echo -n Hello | md5sum 8b1a9953c4611296a827abf8c47804d7


1

I have not encountered a site that actually sends a new password in years. What they do is send a password reset link that expires fairly soon. The lengthy character string won't be brute-forced anytime in this universe but is simply matched (and expiry time checked) to allow you to enter a new password of your choosing. Good sites will do that on an SSL ...


8

If they are indeed sending you a new password (i.e.: a system-generated password other than the one you previously had) when you click 'forgot my password' then no, that doesn't mean they're not hashing passwords. They can have their forgot password function generate a password, hash it and store it in their database, and then (while it's still in memory) ...


0

Under some conditions, your hashes might leak sensitive information. This depends on whether or not an attacker can guess the content of specific files. As a trivialized example, let's say your files are memos from your boss which say which employee they are going to fire. They are always simple ASCII text files in the form of The next employee we fire is ...


1

SHA-1 produces a 160 bit hash. Hashing any file longer than 160 bits (20 octets) will therefore necessarily lose information and makes reconstruction impossible. In theory, that is. On the other hand, hashing files shorter than 20 octets is highly likely (practically guaranteed) to produce a 1:1 mapping. A 1:1 mapping means that without salt, it is trivial ...


0

Question: Do you want to publish the sensitive file names on the internet? Your approach above seems to imply that you will be publishing your file names on the internet. You may not want your file names published on the internet. brain@brain-laptop:~/Secret Files$ sha256sum * c988f4a50da6021fc70f618faeb5e27891b5de7162fb395b1dfd5b42f76a8070 Blueprints ...


2

The security you are thinking of with regards to the hash strength and the security you are talking about with the hashes on the internet are two different things. Hashes like SHA* are designed to work quickly so that files you send and the file you receive can be verified to be the same, however, this makes it easier brute force, due to this speed. What it ...


5

It's actually not a SHA1 hash in the CSR. It's a signature of the message. For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended ...


0

Here is an the essential reference to the algorithm description from which it can be seen why a hash gets always the same length: 3.1 Step 1. Append Padding Bits The message is "padded" (extended) so that its length (in bits) is congruent to 448, modulo 512. That is, the message is extended so that it is just 64 bits shy of being a multiple of ...


1

I've never heard of a specific name for these types of password transformations. However, they often involve the use of a "master password" and "site password". You can do some searching based on those terms and filter out the irrelevant results. Here are a few examples of similar schemes that are implemented through software: ...


0

First of all on of the requirement for modern encrypting standards was that the having known an algorithm by attackers doesn't decrease a protection of the system if all rules, in particular, for keys, are done. Think about that many of algorithms are open source, in fact, any in Linux. So the basic concept of security here is the strength of keys used.


0

You are talking about either a witty (or clever) password or a key derivation algorithm (that is being shoehorned in to producing a "concealed" password). Neither provides any additional security beyond the original password complexity. Either the system is insecure because it is too simple and able to be reverse engineered, resulting in catastrophic ...


2

What you describe is a witty password: a password which relies on the user knowing some specific generation method. This is bad. Witty passwords are not secure passwords; they more are quite the opposite. When you use a "witty password", you rely on the attacker being less smart than you. Self-confidence notwithstanding, this always fails. Attackers know ...


3

Most cryptographic hash functions operate on a fixed-size internal state and process the message to be hashed block by block, where a block is a number of bits. MD5, SHA-1 and SHA-2 follow the Merkle-Damgård construction which operates as follows: Let S be an array of N bits, initialized to a predefined value. N is the size of the internal state and may be ...


1

Hash functions are defined to map inputs of arbitrary length to outputs of fixed lengths. From this it is clear that hash functions are not bijective maps, i.e. there must be collisions of input values. As of how a hash function manages to produce constant length output algorithmically: most modern hash functions operate block-wise on their input, padding ...


0

From the perspective of having such a simple answer like a mother's name protected ,for example, on the web server side - the answers are more than likely hashed in there. The same story is for your local machine, for which you administrator password, be it even so simple, as mother's name, is also kept in hash form. So, keeping the hash instead of the ...


-3

Result of hash-function is a number padded to the string of a fixed length. Number has a maximum (it is different for different functions). Hash-functions, roughly speaking, are calculated in cycle where each cycle modifies the number. If result of operation is larger than max then number overflows. You can start from wikipedia: ...


3

it depends on how you plan to use the answers. If you expect to do strict automatic checking then treat them as passwords and apply key-derivation function such as bcrypt/scrypt. (But remember, that BCrypt uses only first 72 characters of string for the hash. is that enough for your case?) on the other hand, if there is a chance of phone-based support and ...


3

You're overcomplicating the solution, and not really gaining much out of it. Others have gone over the flaws with your implementation, but I'll outline a better approach. When a user chooses to have their authentication remembered across browser sessions, use a CSPRNG to generate a random 128-bit string. Send them this string, then hash it (SHA-2/256 is ...


1

Running a few thousand iterations or appending a very long salt is not necessarily the best way of making a hash run slow, but it is the most obvious (easiest) one. The intent is first and foremost to slow down massively parallel attacks. An attacker will not be able to brute force your hash in reasonable time on a single CPU. He will be using either a ...


0

I'll echo glidersecurity's comment on UUIDs with a Wikipedia link: http://en.wikipedia.org/wiki/Universally_unique_identifier#Variants_and_versions With your current solution (if I'm reading it correctly), if an attacker gets read-only database access, they only have to supply cookies like so: foreach userID in the users table: foreach random_number in ...


2

Just because a UUID is highly likely to be unique doesn't mean that it's difficult to guess. Version 4 UUIDs contain 122 random bits, and I would recommend that or version 5 (SHA-1). Honestly, I usually use SHA256 or higher and a long string of concatenated random numbers. Then store the hashcode in both the database and a cookie. There isn't much benefit ...


6

This attack is not about generating a modified SHA-1 that makes collisions easier, it's about generating a modified SHA-1 as part of the process of generating one specific collision. The modified hash function so produced is only useful for creating the single collision used in the generation process; it is no more vulnerable to collisions in general than ...



Top 50 recent answers are included