New answers tagged

0

Can we Calculate/Figure out/Find out? = NO Can we efficiently Bruteforce? = YES --- ANSWER BELOW IS FOR BRUTEFORCE --- By the design of Cryptographic Hash Functions, they are 'one way'. i.e. can not be reversed. But just in case you stumble upon this scenario (super rare in real-world and common in CTFs). You can use Hashcat(tool) to Bruteforce with masking ...


5

One of the possible ways to do this without having do do the amount of hash calculations that you mention is, at the moment of creation of the password, to calculate the hash of your password as it would have been entered in a numeric keyboard, so the database would have both hashes stored, and would just need a simple comparison to the corresponding hash to ...


0

It's definitely supported, and definitely one of these format names (one for CPU, and the other for GPU): $ john --list=formats | tr ',' '\n' | grep PBKDF2 | grep SHA1 PBKDF2-HMAC-SHA1 PBKDF2-HMAC-SHA1-opencl At this point, it sounds more likely that your method of generating PBKDF2-HMAC-SHA1 is the issue here. Have you tried your attack against a "...


0

The other answers are very helpful and are probably the best solutions for scalability and larger companies. I neglected to mention some extra information about our situation (we are a small company and we already have some users on our main site). Looks like I've overlooked the fact that I can simply associate an API key hash with a user by adding a column ...


0

Transitioning from one hashing scheme to another is nothing really out of the ordinary, and is something that systems sometimes do. If you have a password hashing scheme that is less than ideal, and you want you improve it, you build it so that new passwords (including password reset from that point onwards) use the new hashing scheme, and old passwords ...


-1

Recently, with the hacking of a lot of databases, there has been a rash of emails going around that claim to have hacked you and been watching you over your webcam and will release embarrassing data if you do not pay them. They will then have some gibberish and a message about knowing your password. Usually, in the gibberish, you will see your password and ...


36

While Royce's answer is correct in that wrapped hashes are weaker than unwrapped pure bcrypt hashes, it must be noted that they are nevertheless significantly stronger than your current implementation with a weak hash algorithm and no salt, since an attacker would have to go through the effort of individually attacking each hash, instead of simply using ...


0

Divide and conquer. The problem in your approach is, that you want to use one key for two different things: for authentication and for authorization. If a key is used for authentication, it should be kept secret. If lost, it cannot be restored and a new one should be issued. If a key is used for authorization, it should not be secret. It should be open, so ...


0

If you hash the keys, it would not be possible to show the keys to the user ever again. Hashing can not be reversed. You can only check if a given key is linked to the user. What is oftenly done for APIs is to create a key consisting of a public and private/secret part. The public part can then be stored in your DB, whilst the secret part follows your ...


87

As a password cracker, I encourage all of my targets to use this technique. 😉 This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt. (EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so ...


1

This depends entirely on 1.how your jdbc application is written The options the JDBC vendor has provided for connection. JDBC is capable of sending passwords in the plain and this can be seen in clear in the JDBC logs as well of such jdbc connections. JDBC Vendors expose APIs that can overcome this using different methods of encryption and hashing. In ...


4

As you have seen, the general consensus is that you need to salt and hash server side, and send everything over TLS. While you can do hashing or encryption on the client side, it does not protect against the threats you are concerned about. Many companies, schools, and government agencies that provide network services on site have provisioning profiles or ...


22

It's my understanding that the most widely used method is to hash and salt the password server side and to rely on TLS/SSL to protect the password in transit. This is entirely correct. The main question that remains unanswered to me is what if TLS/SSL is breached? Then you are in a lot of trouble, and nothing else much matters. In the context of the ...


2

The commas appear to be somewhat unrelated. When the commas are removed, most of the digits are in groups of three. At first, it looks like a shifted ASCII substitution, just as Marc suggested - but with some variation: 109 = f (102 ASCII +7) 108 = e (101 ASCII +7) 115 = l (108 ASCII +7) 115 = l (108 ASCII +7) 109 = f (102 ASCII +7) 000 = a (???) Note ...


3

Given the original length L of the string, you could consider that the effort to retrieve it is 92 power L (92 is 26 lowercase + 26 uppercase + 10 digits + 30 punctuation) instead of 2 power 256. So if your string is more than 39 chars long, knowing the lenght gives no help. EDIT: we should consider that an opponent which tries to recover the original string ...


1

There are 2^256 hashes, so approximately 1 in 2^256 strings will have a particular hash. Therefore the number of strings with that hash is approximately the total number of strings divided by 2^256. How long is the length? There are a lot of strings to try. You'd have to use up all of the sun's energy just to count to 2^256, never mind hashing. But if the ...


1

You have two issues here: logging sensitive data in plain files, and password hashing. Logging sensitive data Don't do this. This includes passwords, other security tokens (session IDs), racial or other data labeled as sensitive under GDPR or your local jurisdiction, and other data that sysadmins don't need to help in debugging. If you have a stupid manager ...


2

First let me say that you should never ever be logging passwords, but it seems from the question that the company you worked for was worried about inadvertent logging. Maybe they have some kind of logging software on their server that stores all communications including when you send the password. Simple hashing offers a very small level of gain. As others ...


2

It won't help the client, as many others have said, because hash(password) is enough for a malicious party gain unwanted acess. But at least password won't end up in a wordlist, if the server is hacked and all the logged hashes become public.


20

Almost never. As others have pointed out, this just replaces "SECRET" with "HASH(SECRET)". To make things worse they log the hash, which is now the password. This is because the client is authenticated on the basis of the hash it transmits, alone; so, knowing this hash either by intercepting it at the client level or by lifting it off the ...


11

Sending hash instead of password does not solve the problem with logs. If an attacker get access to logs and can read hashes, then knowing password becomes not necessary. In the login request the attacker will just send the hash retrieved from the log. The server will not know if the client has password and created a hash, or if the client knows only the ...


1

It does not, proper hashing requires iterations and salts, which with client side hashing can't be achieved (e.g. without the system knowing the salt and actual password it can't verify it). If you are just doing a normal hash, then you just replace the secret like Marcus is pointing out. However the proper way of fixing is - is to use tokenisation or ...


3

No, that's not a good reason: This never helps. This architecture just replaced the secret "password" with the secret "hash of password". Neither can ever fall into the wrong hands, because the hash is sufficient for logging on. (You can never assume the client has unmodified software. A simple debugger is sufficient to make a client ...


Top 50 recent answers are included