Tag Info

Hot answers tagged

31

None of the existing answers cover the critical part of this question to my satisfaction: what about the salts? If just the password hash values were posted, other crackers can't possibly know: The actual per-password (supposedly random, per the source) salt value. How the salt is mixed with the password in the code. All they have is the final, ...


16

Edit: All of the below assumes that the salts are known, because that's the industry-standard use of the word salt (3rd line). Just as an example of how this often looks in the database, have a look at this SHA-256 Unix Crypt output: $5$rounds=80000$wnsT7Yr92oJoP28r$cKhJImk5mfuSKV9b3mumNzlbstFUplKtQXXMo4G6Ep5 .. where wnsT7Yr92oJoP28r is the salt in ...


9

No. Litecoin uses an algorithm called scrypt which has variables that determine the amount of CPU/RAM required to compute hash. Litecoin's scrypt parameters are fixed at N = 1024; p = 1; r = 1. (http://cryptocur.com/litecoin/) Users of Scypt for password hashing purposes should have the parameters set much, much higher which will put password cracking out ...


9

Ability to compute a lot of hashes very fast with dedicated hardware is a problem for password hashes, but not a new problem. Before the advent of ASIC specialized in SHA-256, we were already taking FPGA into account (see for instance this research machine, from already five years ago). An ASIC can roughly be clocked at two to three times the frequency of ...


8

Such hardware may make life more difficult for people who rely on PBKDF2 for password hashing. Password hashing functions are intentionally slow -- slow for the honest server and for the attacker alike. We want it to be as slow as is tolerable for the server which uses it, so that it becomes (hopefully) intolerably slow for the attacker. The defendant's ...


8

Cracking unsalted hashes is fairly trivial: you just look up hash in a pre-computed table and find your answer. No sense brute-forcing the rest because your rainbow tables already cover your brute-force dictionary. But cracking salted passwords is still simple; slower but still simple. In most brute-force attacks, the attacker goes for breadth not depth. ...


7

As far as I can tell, your scheme is this: Compute scrypt(pass) and store it as the authentication key in your database. Compute sha256(scrypt(pass)) and use that as your data encryption key. The problem with this technique is that an attacker with access to your database can simply compute the SHA256 hash of your scrypt hashes to gain the encryption ...


7

It stands within reason that they are not lying. As @Jeff noted that access to the salt is essential for fast cracking, but as @Remus Rusanu noted: "if they obtained the hashes then is hard for me to see how could they not obtain the salt as well" since they must be stored in a such a way that they can be associated with each other. I would assume that: at ...


6

From looking at it for two minutes: Using bcrypt is sound. SHA-256 is one of the best known hash functions (because it has been around for more than 10 years, widely deployed, and yet unscathed). Since you generate a new salt for each encrypted file (and that's good !), it would make sense to store it in a file header. That way, you would not have to ...


6

Many cryptographic algorithms (hash functions, symmetric encryption...) are organized as a sequence of "rounds", which are more or less similar to each other. It was empirically noticed that for a given algorithm structure, usually, more rounds imply more security; precisely, some classes of attacks (e.g. differential and linear cryptanalysis) see their ...


5

Though SHA-256 nominally offers a 256-bit output, no weakness about it is known when the output is truncated to 128 bits, except, of course, weaknesses inherent to the shorter output length; e.g. collision resistance drops from the infeasible 2128 to the possible (but hard) 264. This is not a generic property of hash functions(*), but it is somewhat ...


5

The length extension attack that @Tinned_Tuna talks about would have allowed you to generate forged tokens with a "public text" of your own choosing (within some format constraints due to SHA-256 padding, though), but only if the secret had come first in the hash function. By inputting the secret last, this specific weakness is avoided. Another, less ...


5

NIST publishes a lot of test vectors. Including for HMAC (near the end of that page). In the file contained in the Zip archive, the vectors for HMAC/SHA-256 ought to be the ones with the parameter "L=32".


5

By construction, bcrypt is its own function, and does not use a hash function like SHA-1 or SHA-256. You may be confusing it with PBKDF2. Your requirement on "entropy" is, at best, severely misguided: As long as your attackers cannot convert the whole mass of the complete friggin' Galaxy into energy to run some humongous computation, 256 bits of entropy ...


4

SHA256 has never been considered a secure algorithm for password hashing. Use bcrypt, pbkdf2 or scrypt instead. See this is amazing answer by @ThomasPornin for more information.


4

hashcat can do just over 1 billion SHA256 hashes per second on Radeon HD7970, which is only half the speed of SHA1 and a quarter of the speed of MD5. However, this isn't even the bottleneck: One more thing before we move on; did you notice the speed of the cracking was “only” 258.7M per second? What happened to the theoretical throughput of a couple of ...


4

The short answer is, use bcrypt, not SHA256. Bcrypt already hashes the password, so if you are using bcrypt, there is no point to use both bcrypt+SHA256; it won't be any stronger. Bcrypt alone is sufficient. There's a lot of advice on this site on exactly this topic. Search for "password hashing" and you'll find it. See, e.g., How to securely hash ...


4

Recomputing secret from SHA-1(secret || suffix1) (for any known value of suffix) would constitute a preimage attack. No preimage attack faster than luck is currently known for SHA-1 ("luck" works in average effort 2160 for SHA-1, i.e. totally infeasible). You won't get the secret value. However, if your goal is to compute SHA-1(secret || suffix2) then that ...


4

Basic rules: Code with "admin privileges" can do everything it wishes with your machine. You cannot protect against it. At best, the malicious code will have to wait for the next time you type your password, at which point it will plunder your private key (and all your secrets). The same "admin exploit" will modify your icon overlays so as to hide any ...


3

The document your are reading uses the flawed analogy "encrypt with the private key". In asymmetric encryption, you encrypt with the public key, and you decrypt with the private key. "Encryption with the private key" is the way digital signatures were first described, because that kind of works like that in RSA. But the analogy does not work with other ...


3

ASICs are usually OTP (one time programmable [they are made directly from wafers]), so you can't reprogram them (e.g. switch to SHA1 or implement HMAC) and use them for cracking. Bitcoin uses two times iterated SHA256 (Mining), which is pretty useless in security considerations. Please refer to Wikipedia concerning ASIC


3

If your IV is derived from the plaintext, so that encrypting the same plaintext twice leads to the same IV, then you lose semantic security: someone can tell whether two plaintexts are equal by comparing the ciphertexts. Other than that, for CFB, it is ok to use a predictable IV; what is critical is that the IV is not reused (or at least not reused for ...


3

Neither post makes mention of whether or not the perpetrators gained access to Formspring source code. If this were the case, the method of hash construction and random generation of the salts would be available to the attackers. This would make the task of cracking significantly easier, particularly if the method of generating the "random" salts limited ...


3

Both options are secure but the first is preferable. Your first proposal is to use scrypt(password) as the encryption key and SHA256(scrypt(password)) as the password verifier. This is fine. Since it's computationally infeasible to calculate a SHA256 preimage it will not be possible for an attacker to calculate the encryption key from the password verifier. ...


3

First of, a hash function has an input: you hash something. GUID (actually UUID) don't have any input. To generate "unique identifiers" with a hash function, you just don't use a hash function; you have to define what you are actually hashing. There are several standard methods for generating UUID; all these methods aim at achieving "uniqueness" of the ...


2

Firstly, to address the "72%" part: Nope. They're more or less at the same level security. Let's look at another quote on the page: There are two meet-in-the-middle preimage attacks against SHA-2 with a reduced number of rounds. The first one attacks 41-round SHA-256 out of 64 rounds with time complexity of 2253.5 and space complexity of 216, and ...


2

Have a look at this blog post: the author has apparently observed the same lack of SHA-256 support in the Rfc2898DeriveBytes class of .NET, and set out to write his own code. (I have not looked at that code and cannot vouch for its quality.) Otherwise, it would not be too hard to reimplement PBKDF2 with HMAC/SHA-256, following the description of RFC 2898, ...


2

How are GPU's provisioned for password cracking? Do all, if not most cracking programs have special GPU aware software or do they just function at the basic driver or API level of the device? Can it be as simple as plugging in a video card and installing a driver? No, it is definitely not that simple. The password cracking application has to be ...


2

Which algorithm is best depends on what you're using it for. If you're trying to spot random data corruption, for example, a blindingly-fast algorithm like CRC-32 is ideal. On the other hand, if you're trying to secure password hashes, you want an inherently slow algorithm like bcrypt. For protecting data transfers against malicious tampering, you want a ...


2

When in doubt, use SHA-256. This is the default answer for situations where you need a generic hash function; for specialized cases such that hashing passwords, the situation is different: you don't want to use MD5 or SHA-1 or SHA-2 or SHA-3 for passwords, but something like bcrypt. SSL is a deployed standard with a long history, and typically uses SHA-1. ...



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