Tag Info

New answers tagged

8

No actual break involving SHA-1 and using a structural weakness of SHA-1 has been currently fully demonstrated in academic conditions, let alone in the wild. The best we have right now is a theoretical collision attack that should allow an attacker to compute a SHA-1 collision with effort "about 261", which is huge but still substantially less than the 280 ...


2

There are currently three accepted password hashing algorithms (note the difference between encryption and hashing!): pbkdf2 bcrypt scrypt So you can use either of these three. PBKDF2 is the most supported. Storing passwords in a reversible way is considered bad practice.


1

None, assuming you weren't trying to make a collision. MD5 has a length of 128 bits, giving 64-bit resistance to brute-force collision attacks (i.e. you need to hash 2^64 random things to expect a collision). There have only been around 2^40 microseconds since 1/1/1970, so you wouldn't have any collisions if you picked inputs randomly. You'd have to try to ...


1

The tricky thing is not to have two collisions out of the void (even if this must not happen with secure cryptographic hashes, otherwise it is considered not secure anymore). The tricky thing is to find a collision against a known hash. For instance, be able to produce a different certificate producing the same hash so the signature would remain valid, be ...


6

The site does only provide a rainbow table (a lookup of the possible text from the hash). So it is simple a database with all hashes saved (so far because a user has entered the text for the searched hash before). If you enter a hash value (e.g. ...


5

Simple Answer: Rainbow Tables This site save every Hashvalue you Entered to Hash it. So it could reverse search it in his own database.


0

Nice project but as usual you really should not reinvent the wheel. Writing such protocols for production use is a bad idea in almost every case. I recommend reading Bruce Schneier's Cryptography Engineering book. It is not a light read but would definitely clear out all your questions. First of all I think burning keys into executables is a terrible idea. ...


0

Fundamental to the question, is if the endpoint is not secured, keys, whatever they may be can be obtained, which is why for endpoint secure transactions, the terminal itself is under the aegis of the proprietor - eg. atms, cash points, etc.


1

You can't have a private key hard coded in software that is distributed. The two options I see are: Have each client generate a unique key-pair that they use for communicating with the server. Bob would send his public key to the server when he initially connects. The server will then encrypt messages to Bob with his public key. The first communication ...


0

When using SHA256 + RIPEMD-160, you are not only accumulating two different algorithm, but you are also varying your algorithm vendors, since SHA256 comes from US NSA/NIST and RIPEMD-160 comes from the european academic community. While it is true that SHA-3 has not been directly designed by NSA, it went as a winner from NIST competition, and NSA is more or ...


3

I think many of your questions (eg SHA-512 vs bcrypt) are answered in the guide linked to by AviD. But it doesn't actually say anything about PHP, so I'll answer that part. Hashing a Password in PHP5 It's good that you want to understand the underlying concepts, but actually securely hashing a password in PHP5 is quite easy: $hashedPassword = ...


2

The point of strong password hashing functions is to make password processing slow so that attackers find it harder to run a brute force attack on your password. Unfortunately it makes it slower for you too; this is the limit of the exercise. At best, you make the function n times slower for you and n times slower (with the same n) for the attacker; but the ...


0

SALT supposed to be not secret => same for all users <=> no SALT at all. You can see good explanation here: Hashing security


1

Yes, if you use the same salt then the same password will result in the same hash. The general idea behind secure password storage lies in maximising the amount of computational work that an adversary will have to perform should they gain access to the stored credentials. The purpose of a salt is to mitigate the value of pre-computed (i.e. no additional ...


2

As documented rather indirectly in the page for the crypt() function, the "cost" parameter is the base-2 logarithm of iteration count, or to put it another way, each +1 increase to "cost" represents a doubling of the number of iterations. If a cost-10 hash takes one minute to crack, a cost-14 would take 2^(14-10) = 16 minutes. Cracking a cryptographic has ...


0

Thinking a bit outside of the box, you could code a variable to store the md5 of a file (the exact file) and so while the actual md5 of the file in plane text will not be included in the file itself, if the file were runnable code it could be programmed to store a value of its own md5 as a variable. To further enhance such an idea (in order to give it some ...


-2

SHA256 and MD5 are message digest algorithm. You can only encrypt your data using this algorithms. If you want to validate this data then you need to encrypt that data and compare it to validate it. And as you told brute-force is the only way to get that data back and it's too difficult to decode it. If you realy want tha data back then go for AES/DES ...


4

SHA256 and MD5 are hashing algorithms, or "one-way encryption" if you will. A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size (Wikipedia (Hash function)) So to get the (probable*) plaintext that was hashed, brute-force is the only way. There are rainbow tables as well as you mentioned ...


6

This construct can (crudely) protect against a length extension attack, which in particular affects hashes built using the Merkle-Damgård construction (such as MD5, SHA-1, and the SHA-2 family). The gist of the attack is that an attacker who knows H(s || m) and m for a hash H, secret s, and message m can trivially forge a hash of the form H(s || m || p || ...


-1

I am going to base my answer on a couple of assumptions as below. The secret key is randomly generated or not easily guessable The secret key is just that, a secret. Using two private keys in this instance has no viable benefits to security, presuming that the key was never accessed by a third party (So you are looking at reverse cryptographic attacks). ...


1

To expand on @aron-foster's answer, the way that this is done in public key cryptography is to first hash the message and then encrypt the hash using the sender's private key. In public key cryptography, as you likely know, data encrypted with one of the keys can only be decrypted with the corresponding key. This means that when the hash is encrypted with ...


3

Yes, that's correct. That's why if you're using a hash for data integrity then you must deliver the hash by separate means (eg. posting the hash with your twitter account). To get around this problem in emails, rather than using a hash you can use public key cryptography that allows the receiver (and anyone else) to verify the signature using your public ...


0

The nice thing about PHP's password_hash() and password_verify() functions is that they are designed with the future in mind, but they are also designed to be backward compatible. The hashing algorithm that password_hash() uses to create a hash is stored in the output produced by password_hash(), and this is how password_verify() knows which algorithm to ...


1

The new password_hash introduced in PHP 5.5.0 creates a very strong one way hashing algorithm. All information that's needed to verify the hash is included in it. I tried running a loop for 5000 times, and every hash for a single password was a unique hash. To create a password hash you can simply use : $password = '170991'; $hash = ...


2

I also have this following sha512 encryption system, which was created by Sammitch Why not use password_hash? The only reason I can think of is that you are using an old version of PHP, in which case you should update PHP. I have a custom CMS with a randomly generated ASCII 100-character string from this site for both my username/password. Don't ...


3

Flame, a component related to Stuxnet, used a hash collision in the known-weak MD5 algorithm to deepen the level of penetration of the target system. It was not used by itself but as part of a larger set of vulnerabilities, although as a whole it did lead to particularly disastrous results. Here is an article: ...


9

Yes, there are obvious flaws. Here are some: You can't make hashing slow by introducing simple delays. An attacker doesn't have to evaluate the hash the same way you did; they just need to get the same answer in the end. That means whatever is making the hash slow needs to be a necessary component of the hash -- it must be impossible to compute the hash ...


1

no. it looks like you're using a global constant for the salt. you want it to change per user record. see http://stackoverflow.com/questions/2999197/do-i-need-a-random-salt-once-per-password-or-only-once-per-database also, @coverosgene is right - there's no point in slowing your own hash method down.


0

Just ask the admin. Really, my experience is that they'll tell you if they're storing the password in plain text. To answer your question directly, no based on the information you've provided it's not possible to know if the password is stored (locally or remotely) in plain text beyond that session.


3

John 1.7.9 with Jumbo patch 6 has you covered. From: http://www.openwall.com/lists/john-users/2012/06/29/1 New hashes: * IBM RACF [OpenMP] (Dhiru) - thanks to Nigel Pentland (author of CRACF) and Main Framed for providing algorithm details, sample code, sample RACF binary database, test vectors * sha512crypt (SHA-crypt) [OpenMP, CUDA, OpenCL] (magnum, ...


3

According to Wikipedia (summary bar on the RHS), "No actual collisions have yet been produced" for SHA-1. The best we've done is find algorithms that "should" find collisions eventually. Since the point of a hash function is that any change (even a single bit) should change the whole result in a basically pseudorandom way, you're essentially looking at the ...


0

No it doesn't. The password is probably sent to the page where it's displayed to you and at the same time it's stored. We cant say if it's stored hashed or not but displaying the password to you does not mean it's not hashed. Like the other answers, I do agree that it's a terrible idea to show the password on the next page in plain text. It's bad anyhow to ...


5

As others have mentioned this doesn't necessarily mean the password is stored in plain text but is a bad sign and bad practice. Some ways to determine if your password is stored in plain text are: Using the password recovery to see if it's emailed to you (this indicates plain text or 2 way encryption at the most). Check the password requirements, if ...


14

You can't conclude the password was stored in plain text if it is redisplayed soon after you changed it. On the other hand if it is displayed after a while (days for instance) it may be a good hint that the password is indeed not hashed (it is stored in plain text or encrypted). Anyhow, redisplaying a password is clearly not a best practice because it may ...


50

No, you cannot conclude that. The password can be hashed on the server-side only, which implies that the password is sent in plain text to the server and stored in a variable. Then, nothing stops the Web application from displaying the sent password to the user, in the case where the very same script that has received the password is giving you the feedback ...


2

This is something I've spent some time trying to figure out too. The answer is a lot harder then it appears, but quite consistently seems to be "We have no clue". This might seem strange but it's actually quite reasonable when you consider what you are looking for. Essentially you're asking someone to find a collision in a hash function. That is supposed to ...


0

I'd like to to rephrase your question as this: "Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?" I would see two approaches to that problem. The first one starts with the data, the second one, with the final view. Data-centric In order to implement this, you need to ...


1

I'll suggest an answer to my own question. Perhaps I'm essentially helping to define a term that has been introduced elsewhere. If we take the definition of 'hardening' in security as: hardening is any one of a variety of measures taken to make it more difficult for an intruder to circumvent the authentication process Then 'key hardening' is any ...


0

It would need to be researched as to whether or not such an action would produce a collision in practice, but you can consider that a recursive MD5 hash is still only 1 MD5 hash at the end. You are only running the hash on 32 bits of data (the output of your n - 1) instead of on n bits of data. So, considering that the hash algorithm is pseudo-random, you ...


0

A straightforward approach would be to log the IP address and a timestamp in a logfile, and delete entries after a period of time. Straightforward but phenomenally innefficient. Really you should only be maintaining data for violators in indexed storage independent of your log data (you should probably also be keeping log files but that is seperate ...



Top 50 recent answers are included