Tag Info

Hot answers tagged

16

It's just hex encoded. A 16 byte md5 hash can contain non-printable characters, so it's encoded to a 32 char hex string.


13

Actually the '3' is there, but it is called 'u'. Explanations: bcrypt needs a 128-bit salt. The salt you provide should be in "modified base64", i.e. consisting in letters, digits, '/' or '.' signs (this is "modified" because in true Base64, the '+' sign is used instead of '.', and the order is different). Since this is a 64-element alphabet, each character ...


10

we're talking about strongest for password hashing here. A good general purpose hash doesn't need to be a good password hash, and vice versa. Length of the hash is irrelevant once it exceeds a certain threshold. A pre-image attack on an n bit hash costs 2n. For a 128 bit hash this is completely infeasible. bcrypt using an exponential notation for cost and ...


10

By adding more algorithms, you do two things: Potentially increase the strength of the encryption. Increase the attack surface of your application. AES128-CBC is strong. If you're implementing it properly, and using strong random keys and unique random IVs, you're very safe. The US government (NSA) certifies AES for use in securing top-secret documents. ...


8

It is extremely rare that the algorithm itself is a vulnerability. Even weak algorithms such as RC4 are often the strongest part of the system in which they are used. Vulnerabilities usually hide in how you apply encryption (padding, IV randomness, integrity checks...) and in key management. These seemingly peripheral activities are quite hard to do right, ...


7

Under most conditions, a salt needs only to be unique, not cryptographically unpredictable. So in that case, yes as long as your RNG is properly seeded. Another common technique to improve salt quality is to concatenate a random number to the current time, then hash that (e.g. SHA1), textually encode (e.g. base64), and take the first N characters. The ...


6

They do this hashing out of a mixture of insecurity and shamanism. The hashing has no value for actual security. Their salting is bad because mt_rand() is not sufficient to ensure uniqueness (good salts should strive to be unique, and random salts are a good way to get unique values with high probability, but it requires the use of a good random generator, ...


5

Theoretically, Blowfish is supposed to be faster than AES, but not much faster. See this question for some details. Then there is optimization. For a given algorithm, you can somehow define its "top speed" as being the performance achieved with optimal code; but actual implementations are never completely optimal, and how close (or far) they are to ...


5

Your salt doesn't need to be perfectly random, it just needs to be unique for each of your users. See this question on Crypto.SE for more. That's why some websites use the username to derive the salt from (ie $salt=$username.$signup_date). In your case, when crypt says 'blowfish hash' it really means bcrypt so you also want to keep up with Moore's law when ...


3

Blowfish is a block cipher and block ciphers in ECB or CBC require that the length is a multiple of the block size. If this is not the case the last block is padded. There exists several methods for padding. The point is, if the decryption does not result in a correct padding you know that you have decrypted the ciphertext with the wrong key. You can also ...


3

If your "random string" is really a "random string", then none of your tricks can do any good. For that matter, the salt won't make things better either. Neither the use of bcrypt (what PHP calls "crypt with Blowfish"). Indeed, all the games with salts and iterations are just ways to cope with the inherent weakness of passwords. Passwords are weak. They ...


3

Personally, I would avoid multiple encryption protocols most of the time. It adds significant extra implementation complexity without making your data any more secure in the real world, unless the encryption protocol you are using is ultimately broken or becomes computationally feasible at a later date to break. Granted, I will disagree with others who ...


2

You should not use SHA-3 yet. And let's not call it Keccak for clarity's sake, I can't recall what SHA-2 and SHA were originally called so I guess future readers won't know Keccak either. More on-topic, your answer is here: How to securely hash passwords? This protects against dictionaries and all other possible attacks in the best currently known way.


2

You shouldn't need to keep credentials in a recoverable format, even if they are encrypted. If your backend application could decrypt something, then so could anybody who can hack your backend application. Really, you have to assume that sooner or later, your backend application will be compromised and design with that in mind. The most secure method ...


2

Now that the question has been revised, I understand what you're trying to do much better. The short answer is: Just store the database password in the clear, in the (server-side) session object. You cannot do any better. If you want, you can encrypt the database password and store the encrypted password in the session object, but there's really no point, ...


2

As others have responded, hash functions (all of them, including MD5, SHA-256, Whirlpool and the dozens of other functions) output bits. The output of MD5 is 128 bits. However, humans are bad at reading bits. Humans are good at reading characters. So, when a hash function output is meant for human consumption, it is converted to characters with some ...


2

For OpenSSL's command-line program (openssl enc), the algorithm chosen also picks the key size (which is why they have separate options for aes-128, aes-192 and aes-256). They just don't have this option for Blowfish. The enc program only supports a fixed number of algorithms with certain parameters. So if, for example, you want to use RC2 with a 76 bit ...


2

bcrypt is based on blowfish. The difference between $2a$ and $2y$ is something else: There are multiple implementations of bcrypt. And one of them, called crypt_blowfish, had a security related bug, drastically reducing the actual password space. Fixing this bug, however, caused existing bcrypt hashes to not match the passwords anymore. So this ...


1

Blowfish has known key-weaknesses that can lead to the discovery of your plaintext if you happen to pick a vulnerable key. Mark's answer is also fairly accurate, smaller keys equals easier cracking time, and with larger keys it is almost impossible to brute-force. Since Blowfish has key-vulnerabilities, it has been replaced with newer versions (Twofish and ...


1

The difficulty of brute-forcing your ciphertext depends on what key size you used when encrypting: Blowfish has an adjustable key size, ranging from 32 bits to 448 bits; this size is independent of the complexity of your password. At the 32-bit end of things, your ciphertext could be decrypted in a matter of minutes, while at 128 bits or larger, it would ...


1

Above 128 bits in unnecessary. With 128 bits there are 2^128 possible keys, divided by 100 billion tests per second (which would require a formidable GPU farm) and it would take someone 7.8*10^9 times the age of the universe to crack it (about 10^20 years). But in all seriousness I do wonder why there is a limit on the size of the key.


1

I don't know if that holds for blowfish too, but usually the strengths of encryption algorithms is that basically every decryption is a valid decryption. In order to check that the decryption makes sense you would have to check if the text fulfills your expectations. It is possible that the decryption of some ciphertext results in hello world when you use ...


1

First: Are you sure? First, check to make sure whether you really need to store passwords in cleartext, or in recoverable form. Your question did not explain why this is necessary. If you have a security breach, everyone will be second-guessing your decision, and if it turns out you stored passwords in recoverable format, your organization may suffer some ...



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