We’re rewarding the question askers & reputations are being recalculated! Read more.
506

/** Dave's Home-brew Hash^H^H^H^H^Hkinda stupid algorithm */ // user data $user = ''; $password = ''; // timestamp, "random" # $time = date('mdYHis'); // known to attackers - totally pointless // ^ also, as jdm pointed out in the comments, this changes daily. looks broken! // different hashes for different days? huh? or is this stored as a salt? $rand = ...


238

Advantages of a public protocol: Probably written by smarter people than you Tested by a lot more people (probably some of them smarter than you) Reviewed by a lot more people (probably some of them smarter than you), often has mathematical proof Improved by a lot more people (probably some of them smarter than you) At the moment just one of those thousands ...


170

If Dave is really "your" developer, as in you have the authority to fire him, then you have the authority to direct him to use a more well-documented scheme, and you should. In cryptography, the fewer secrets that are required to be kept, the better. This applies especially to "hard-coded" secrets, such as the hash function itself, which are not secrets as ...


99

To be fair to Dave, in terms of homebrew password security this is one of the better cases as all it just a little obsfuscation (and really not much) masking hash = SHA1(salt + MD5'(Password)) where MD5' does a reversible swap of the order of the bytes of the MD5 hash. Now the username/time/random/crypt-part is just used to generate a salt, and the only ...


69

See the related Security Meme post While this may seem very simplistic, the rules hold true - designing crypto algorithms and implementing them correctly/securely is very hard. Even the ones designed by experts and picked at by thousands of people over years have holes discovered in them eventually. So Do Not Roll Your Own Crypto is good advice for ...


51

The private key is unrelated to the passphrase. So is the public key. The public key is also generally stored unencrypted, even when the private key is protected by a passphrase. (Exceptions may exist where the public key is stored in an encrypted form, but in the basic case and assuming a sufficiently large key, doing so provides no additional security ...


43

While we can find plenty of flaws with Dave's algorithm, it really isn't horrible because it isn't 100% home brew; he does use hashing protocols that (albeit weak) are based on solid principles. On the other hand, he takes steps that increase complexity for the developer but do little to improve the security of his algorithm. But the reason I am adding ...


36

HMAC is a Message Authentication Code, which is meant for verifying integrity. This is a totally different kind of beast. However, it so happens that HMAC is built over hash functions, and can be considered as a "keyed hash" -- a hash function with a key. A key is not a salt (keys are secret, salts are not). But the unique characteristics of HMAC make it a ...


32

Any practical brute-force algorithm will take into account the method a password was generated with. If a password was randomly generated. You should assume brute-force algorithm also to be truly random. You don't know what it is, you can't claim one password is faster to find than the other, you can only tell that on average passwords would be discovered ...


30

OK, fire Dave. At the very least hit him with a very large clue-bat. Open protocols are good because anyone can look and attempt to find vulnerabilities and structural problems, and implement fixes. The visibility improves the protocol. Good security means that everyone can know how the system works and it is still secure.


30

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


29

The reason Diceware advocates using dice to select a password is that it ensures the password the user gets is generated randomly. So no, as long as you are certain your program is selecting the password in an unpredictable (cryptographically secure random selection with a uniform distribution) manner, it doesn't matter how the password is actually generated....


27

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


24

Short answer: Kind of, but not really. A salt is simply random data added to the message before it is hashed, with the object of making the hash produced by a salted message different from anything an attacker may have already computed on his own with the same but unsalted message (or with any other salt, for that matter). Usually, salts must be public, in ...


24

The passphrase guards against accessing the private key The passphrase is meant to guard the private key in the event of physical access. If the hacker can sign on to your server and can access your certificate store, he could use the passphrase to obtain a copy of the certificate that would include the private key. Hopefully hackers don't routinely have ...


19

Convince him with good reasoning. Don't berate him. You have to think about why we are hashing passwords: The reason is to protect the original password by making the hashing process take a lot of CPU time to execute. Brute force is the way the passwords are typically recovered. If the attacker is able to steal your password database then they've managed ...


19

From what you describe, what they do is that they tunnel data in some SSL (this is reasonable) but add an extra encryption layer in Javascript (this is not reasonable). The whole reasoning is faulty. Indeed, either the SSL ensures security of transmissions, in which case the extra layer is simply useless; or the SSL does not ensure security of transmission, ...


15

Yes, this is perfectly fine to do. With a good PRNG, each element will have exactly the same odds of being chosen, if you do the limitation (1 to n) correctly. (I have personally done a diceware implementation that does exactly that.) There are two simple reasons multiple dice is used in a physical diceware process: 6 sided dice are ubiquitous and cheap. ...


14

This depends on the algorithm. Especially with asymmetric cryptography, the speeds vary wildly. You may want to check out eBACS for more detailed and machine-independent benchmarking of various crypto primitives. As always, you need to perform your own benchmark on your own system to know exactly what to expect on a production system under the chosen ...


13

How about you take his challenge? Go make a quick rainbow table of common passwords and run it over his database. You're bound to hit something (especially if he doesn't have a password policy). However, this may not work if he has a small database.


12

Basically, you're asking for an asymmetric cipher that can have a block size either equal to your message, or to the character size of your message encoding (8 bits for ASCII/UTF8, 16 and 32 for UTF-16 and -32 respectively). Vanilla RSA can technically do this; you must simply limit the bitsize of the unsigned integer N, produced by choosing two random ...


11

I've written several hashing algorithms. There's nothing wrong with it, if you know what you're doing. In a very slight way, he's right about the fact that tried-and-true algorithms may be a little more vulnerable to attack. So if you can create a good algorithm, you're golden. The only problem is that his totally sucks, for a number of reasons. // ...


11

"Best" implies some gradation on a scale, which should be defined... The most commonly used asymmetric encryption algorithm is RSA. It is good enough for most purposes. RSA has some limitations, which are rather generic (i.e. which apply to most other asymmetric encryption algorithms as well): It can process only limited-size messages (with a 1024-bit RSA ...


11

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


11

An algorithm can be secure only if used properly within a protocol that matches what the algorithm was meant to do. So none of the algorithms you list can be deemed "secure" in an absolute, unconditional way. On the other hand, some algorithms are necessarily insecure and should never be used (for a security purpose). In your list, these are: DES block ...


11

I know that MD5 is the most vulnerable hashing algorithm Well technically (we are technical around here) there are worse algorithms than MD5. and particularly vulnerable to Collisions Yes, folks can create a desired hash with a different plaintext. This is not likely to happen randomly, but could occur maliciously. But the collision vulnerability is ...


10

Steganography would benefit from Dave's operational secrecy better than Cryptography. This might be what Dave was intuitively aiming for. Cryptography Each cryptographic solution benefits from widest possible exposure because relying on a secret other than the private key makes operational security for a crypto-consumer much harder. A key is a single easy-...


10

To find out if a salt is used, try to use the hash the same value again (as if it was a "new password"). If you get a distinct output, then there is some non-determinism (aka "a salt"); otherwise, there is no salt. If the hashing mechanism is meant to be secret, and was done properly, then it is a MAC and you will not be able to rebuild it from analysis of ...


10

Roughly speaking, no, the last statement is not true. See this site for extended information about laws on cryptography in the USA (the same site contains a lot of information for crypto laws in other countries as well). AES accepts three sizes of keys: 128, 192 and 256 bits. The smallest of the three is already way beyond that which can be broken through ...


9

I think the best way to answer your question is to say: the premise is highly implausible, so the issue simply does not arise. I might as well ask: if we suppose that we discover time travel, is there cause for alarm about password security? Sure, if we discover time travel, someone could travel back in time, appear poof just before I enter my password, ...


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