Tag Info

Hot answers tagged

279

/** 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 = ...


133

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


105

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


65

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


54

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


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


26

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.


19

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


13

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


11

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


8

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


8

Looks like the first part is a base64'd 128-bit hash, likely MD5, and the second part is a base64'd salt. In hex: Hash: 8baca03904218946ce15e51bcc8d8bdf Salt: 730b2b5ec0ae66ed0240e3e12ab65b8a2f329eeeeac7d8 If you have other examples of the hash, it'd be easy to verify this.


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


7

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


7

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


6

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


6

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


5

Allowing SSLv2 with weak ciphers exposes you to several potential attacks and is not worth the risk. If you only plan on using strong ciphers, is easy enough to restrict the SA VPN to only allowing SSLv3 and TLS1 with 168bit ciphers on the Configuration>Security tab. You will even note that there is a warning on that page indicating known vulnerabilities ...


5

Chaos is not sufficient. A cryptographically secure PRNG must produce unpredictable output: it should not be sufficient, for someone observing a long stream of values produced by the PRNG, but not knowing its internal state, to predict the next bit with a success probability substantially distinct from 0.5 (i.e. predictions should not work better than luck). ...


5

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


5

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


5

It will be significantly less. I would just set up a recurrence relation for this like so: A(n) = A(n-1) - C * 2 ^ (N-1) and A(0) = size of keyspace, say 62^12 lets set C = 3.0*10^12 for hashes computed the first year and assume computing power doubles every year. Plugging this into wolfram alpha yields this function solution for the recurrence relation: ...


5

In order to find out which encryption method was used, the first thing you can do is look at the length of the key and ciphertext in order to limit and rank the likelihood of the possible candidates: With a keysize of n bits, obviously only encryption schemes apply that support keys of this size. For example: if n is 168, you can be pretty sure the 3DES ...


4

Safely deriving site-specific passwords from a master password is possible. It requires, namely, a deterministic one-way function: "deterministic" so that the site password can be recomputed, "one-way" so that it is not feasible to recompute the master password from a site-specific password. As first order approximation, a cryptographic hash function does ...


4

Covert channel algorithms is most commonly used as a name given to a set of algorithms used in IDS/IPS (Intrusion Detection/Prevention Systems) to detect, analyze and identify covert channels in TCP/IP networks, for example by probabilistic statistical analysis by e.g. using the Markov model TCP packet analysis, Bayesian inference and other algorithms, ...


4

Second, if SHA-512 is not good, is there another algorithm which CPU's or GPU's are good at, but FPGA/ASIC's are not? Yes there is. This particular algorithm is called scrypt which is why scrypt is highly recommended as a password hashing algorithm in the first place. Also, designing a new cryptocurrency. Not a good idea when you don't even have ...


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

The Risk score doesn't mean much without context. What risk does this vulnerability increase? Unfortunately, it's complicated enough to always require some amount of human judgement. One standard way of providing context is by using CVSS (Common Vulnerability Scoring System) Vectors: http://nvd.nist.gov/cvss.cfm?vectorinfo&version=2 CVSS vectors ...


3

This looks weird. An anemic laptop from 2005 generates 4096-bit RSA keys (i.e. huge, overkill keys) in less than 10 seconds. "Several minutes" would indicate that there is something wrong in your system. Or that you are aiming for ridiculously large RSA keys (2048 bits are very fine; 3072 bits are understandable if you have paranoiac managers or must comply ...


3

The primary difference is that RSA is well defined, whereas your algorithm is incompletely defined. This means that nobody can use your algorithm in practice, while RSA is widely used. The secondary difference is that your algorithm has no security proof, assumptions, goals, list of security properties you are trying to achieve, and list of security ...



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