Tag Info

New answers tagged

0

If you're hashing arbitrary data, there's no easy way to reconstruct it, since it doesn't have a predictable pre-hashing size. The reason password hashes that aren't salted are dangerous when leaked is because you're dealing with a very constrained set of possibilities. Without a salt, the password of "password" will always result in the same hash. This ...


1

It sounds like your problem could be solved with anti-CSRF tokens or maybe you have them elsewhere already? See link below for details. Basically, with each form request a unique token would be sent and validated by the server. If the token is invalid, the request is blocked. The token would be unique, valid for that request only, and a malicious user would ...


1

Similarities Both a dictionary and brute force attack are guessing attacks; they are not directly looking for a flaw or bypass. Either can be an offline attack or an online attack. An online attack tries automated routines providing input to a legitimate system. They are not looking to create an exploit in functionality, but to abuse expected ...


1

If the salt used for PBKDF2 is of non-trivial length, say 128 bits, and the salt is stored with the form ID on the server (only), then this will allow you to check whether the form ID has been tampered with. There must be a secret component to the hash because of Kerckhoffs' principle, AKA Shannon's maxim. In this case, the salt, stored only on the server, ...


2

You are correct that brute force attacks are feasible, especially if the data being hashed comes from a relatively small search space. Here is a recent example where New York cab details were inadequately disguised using a hash. From the article: It turns out there's a significant flaw in the approach. Because both the medallion and hack numbers are ...


0

plain hash is not secure if the attacker plans to retrieve some passwords using a rainbow-table attack (or other brute force techniques). Appending the salt should make the hash reasonably secure, even if released to the public. "unbreakable hash" doesn't make sense. If you use a weak password (e.g. "123456") and don't use salting any strong hash function ...


2

With your proposed system, anyone who intercepts the login transaction can store a copy of the password hash and use it in place of the password to impersonate the user. If you really can't use SSL to protect communication, look into challenge-based authentication systems, where the password is never transmitted over the network, but instead proof that the ...


0

Dictionary Attack: The attacker tries a list of known or commonly used passwords. Thus, s/he tries a list (dictionary) of passwords. Generally, dictionary attacks succeed because many people have a tendency to choose passwords which are short and easy to remember like superman, harrypotter, etc. Brute Force Attack: Does not use a list of passwords; instead, ...


4

A brute force attack means probing the complete keyspace on the algorithm. A dictionary attack means that you probe only passwords/keys from a dictionary (which does not contain the complete keyspace). A brute force attack is primarily used against the encryption algorithm itself (you can also use this against passwords but there you use dictionary attacks ...


0

I've actually pondered this exact issue before. If your API key is basically only used for insertion, the real issue is the key leaking and bad data getting into a user's account. It sounds like you have adequate security controls for what is truly important: user access to data. I don't see any need to hash these necessarily. Ideally any authentication ...


2

Just XORing the plaintext blocks doesn't prevent some types of attack. For example: If the first or the last block of the message consists entirely of null bytes, you can just delete the IV (so the first encrypted block will be considered the IV) or the last encrypted block and the message will still be judged as valid. In the same fashion, if the first ...


0

It's a fair question there are considerations you may not have thought of: There are ways attackers can get access to parts of your database without accessing all of it, so your point 2 isn't quite correct. Coding errors can leak data, as can sql vulnerabilities. An attacker could get a dump of your passwords and nothing else If you aren't storing your ...


7

The decision to use SHA1 for message authentication is part of the formal transport design specification (RFC 4253). Furthermore, SHA2 is now recommended as an update to the protocol (RFC6668). According to this reference the use not only ensures data integrity but also prevents replay attacks. SSH was originally more like what you are suggesting using ...


5

Strictly speaking, it's not about "consistency" but about "integrity", i.e. the data B receives is the same that A sent. XOR is a simple and reversible operation, with many possible attack vectors even for encrypted data. An attacker may for instance change one bit from 0 to 1 and another one from 1 to 0 in the ciphertext and this may go undetected by XOR. ...


5

Just a guess, but XOR isn't a great way at detecting defects in data, and therefore isn't a great way to checksum something. If you XOR each of the blocks and have a bit error in two of the blocks in the same position, the final XOR value would be the same as if there weren't an error. With a hash checksum, any small change would be reflected in the final ...


0

You don't need to crawl through ALL combinations - you just need to find ONE that you are not authorized to access. That proves the method is broken. Because it is an MD5 hash, it is also likely the same length each time, which makes it easier to narrow in on a valid link. I believe that a crawler would take less than about 5 lines of code, and less than ...


2

There are a couple of issues to consider with "secret" URLs. First, they offer a different level of security against discovery when served over HTTP vs. HTTPS. Over HTTPS, the path is protected. Over HTTP, it is not. This means that when using HTTP, anyone in the path of the traffic (people sniffing wireless traffic, proxy servers, caching servers) ...


16

The browser already contains a copy of the root cert. Thus, it doesn't need to verify it through its signature. Even if you broke SHA-1, you couldn't replace the root certificate that is already stored in the browser.


6

For non-root CA certificates, the browser can only verify the certificate by validating the signature of the certificates hash. If the signed hash was generated by a weak algorithm, an attacker may be able to create a fake certificate with the same hash, but a different key pair. For a root certificate, however, this does not have to be a problem. Since the ...


18

A root certificate is a self-signed certificate (by definition). So how do you want to verify the signature of a root certificate? The root certificate is valid in itself, therefore you cannot verify it. This is also the most problematic part of root certificates: they cannot be validated independently. If they are in the browser, then they are trusted.


2

As @Andrey said, problems, problems, problems. And here's a list of few collisions to Password1. I can produce tens in a second with a simple program: HAPPOAAA AHPPOAAA HAPOPAAA AHPOPAAA HAOPPAAA AHOPPAAA ECPPPAAA CEPPPAAA NNFEOCAA NNEFOCAA EAPPPCAA AEPPPCAA NNFCOEAA NNCFOEAA CAPPPEAA ACPPPEAA NNCEOFAA ONOKOHAA NOOKOHAA AAPPOHAA AAPOPHAA AAOPPHAA ONOHOKAA ...


3

It is not. There are bunch of problems here: You has function produces 32-bit value, which is nowhere near sufficient for password hashing. For such short hashes it's feasible (and easy) to simply find colliding password (i.e. password that's different from the original but still hashes to the same value); Function looks simple enough to be "reversible" ...


2

This is how I understand it, please correct me if I've misinterpreted something. Sending Password in the Clear A one time risk is never worth it when it can be avoided. Using a secure algorithm like bcrypt or PBKDF2 with a salt does not require the password to be sent in the clear. Even if the password is sent under TLS, am I to trust that you're not ...


4

Is this a secure way to hash passwords? Probably, but a lot of your additional complexity isn't really adding much security value. The idea of a salt is to ensure there is no method more efficient to recover your passwords than to brute force every single one of them from scratch. Therefore your goal is to ensure no two accounts have the same salt (ie. ...


6

No, this is not possible. A salt protects you from collisions in the hashed password, not collisions in the plain text password. If two users have the same password then you'll have two password/salt/hash combinations which pass your validation and you won't be able to distinguish between the users. The problems you're having with how to look the users up ...


8

That's really a very bad idea. Consider two people using a similar password where the two letters match. How will you be able to distinguish between the both of them? Not. We use username and password to identify someone. If you just need to protect the application you might as well share a password since you don't seem to care about accountability.


0

I don't see anything that indicates that "Security (bits)" is looking for a preimage attack vs a collision, so I think your assumption that the birthday paradox is irrelevant is probably not accurate. Collisions are still a significant security problem, in fact they've been used to forge SSL certificates. A preimage attack (finding another input that ...


0

You need to store the secret key in encrypted form in the DB so that even if the DB gets compromised, your key is in encrypted form and is of no use to the attacker unless it gets decrypted. In addition, you need to have a mechanism using which your key gets decrypted on the fly whenever you need to use it. Added DB stores your data and your application ...


0

Not very familiar with how a server would be able to hide a global pepper constant but my take is that sooner or later a hacker that has penetrated the server will figure out how to capture the pepper value. To make a pepper value totally secure would require special hardware. One way to do this would be to use a FPGA board installed in the server. The ...


4

SHA-1 is 160 bits (or 40 hexadecimal characters), whereas MD5 is only 128 bits (or 32 hexadecimal characters). Using this file as an example, the Info Hash is: 353E1F88B06C7AFBEB0692E25CE75F05A9E44FB0 Which is 40 hexadecimal characters, so I assume it's SHA-1. Note that this value isn't the hash of the actual file you're trying to download, rather: ...


3

You are misunderstanding the purpose of TLS (https). If you have a https connection to that server that means that all traffic is encrypted during transport from the client to the server. This includes any credentials. As for "disguising" the passwords on the client side with some rudimentary charter rotation and replacement - that would add absolutely no ...


1

The RFC for CSRs - https://tools.ietf.org/html/rfc2986 - actually gives a different reason why the CSR is signed. It doesn't say anything about preventing the CSR being modified in transit, but says that it is to prevent someone requesting a certificate for a key that is not theirs (and says this is only a minor issue): " Note 2 - The signature on the ...


12

"c/s is "crypts" (password hash or cipher computations) per second" Quoted from the John the Ripper FAQ: http://www.openwall.com/john/doc/FAQ.shtml


1

Yes, if the "salt" is a secret word, it is possible for a user to calculate the hash by running a simple dictionary attack until they come up with the correct hash for their adid. It's not clear to me why you need a token at all. Is this just for some logged out users rather than all logged out users? Regardless, if you do need to provide the user ...


1

I found the answer. Turns out what I asked for is called a Message Authentication Code or MAC. There are various implementations for it, based on hash functions as well as block ciphers. HMAC is using hash(key || hash(key || message)) pattern with some additional padding.


0

MD5's are great, but not for security. Yes, it will, in theory, add some additional level of security, whether or not it is enough depends on your application. You have to look beyond added security. What does it cost to hash the hash as opposed to starting with a far superior algorithm. Despite a theoretical added security, if you need to hash an MD5, you ...


2

This particular implementation is naïve and doesn't help. A stock PC can calculate billions of MD5 hashes per second, so having to calculate some more simply isn't relevant. The concept of iterated hashing is valid, though. If you look at professional algorithms like bcrypt, they actually do repeat their internal hash procedure in order to make the ...


3

Assuming the hash is being cracked using brute force techniques, hashing the hash would mean that theoretically you will need more time and resources to crack that hash due to the fact that you need to execute multiple iterations of the algorithm. However, having said that, if it is time you are looking for MD5 is most certainly not the way to go. In order ...


-2

I believe the answer would be that it would add some extra security, but I don't believe it would prevent against collision attacks. MD-5 has been determined to be weak, and other algorithms are now recommended. See http://en.wikipedia.org/wiki/MD5 for further information. It would probably be much better to use one of these newer methods.


0

Yes, it is an extra level of security. For standard md5 (other than the fact that it can be cracked quickly) there are massive lists of already cracked md5 hashes. However, if you reuse the hashing algo a couple of times, it will be harder to crack the hashes. That is called "rounds". Some algorithms have a default amount of rounds to slow down the ...


1

The thing that you are asking about is called hash collision. To make it extremely simple let's say your hash has 1 byte (=8 bits). This means that you can assign a distinct hash to at most 2^8 messages. If you had 2^8 + 1 (257) messages you would definitely experience a collision. Now let's fast forward to todays situation. MD5 for example has 128 bits. ...


2

Yes, it's possible because of the limited length, but it has a very little chance. Read a bit about hash collision, for example: http://preshing.com/20110504/hash-collision-probabilities/


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

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption. bcrypt(cost, salt, input) state ...


0

Common practice is just to use any hash algorithm, such as SHA-2 on the client. For slightly more security, a slow hash can be used such as PBKDF2, bcrypt, or scrypt. A slow hash is a hash designed to require a great deal of computational power, making brute force attacks with lists of common password more diffucult. The actual security advantage of slow ...


3

Bcrypt is not reversible. You can use it client-side as well as server-side. The key is not static but rather dependent on the password, generated by the function call EksBlowfishSetup(cost, salt, input). The plaintext is known and public, its "OrpheanBeholderScryDoubt". If you wanted to retrieve the key, you would need to mount a known-plaintext attack on ...


1

Edited to add: It turns out that what I've written is correct, but it isn't an answer to the question that was asked. I apologize. Whatever you send from client to server is the password, whether it has been hashed, sliced, or diced. A password hashed on the client is no more secure than the same string, unhashed. If it is intercepted, it can be used for ...


8

This is extremely unsafe, to the point of being pointless: Your hash function is not a one-way function. One can instantly (with constant and low runtime) calculate an input producing any given hash if you allow arbitrary 4 character passwords as inputs by undoing the XOR with the initial hash value formed from the password length. With a little ingenuity, ...


6

32 bit hash function cannot be possibly safe for the purpose of password verification. Problem here is that it is "easy" to find a colliding password, that is, a password, that hashes to the "correct" hash value despite being different from the original password. On average it will take 2^31 password trials to get such collision, which is considered very ...


2

The reliable way to check this, I think, is to put yourself into attacker's position, dump hashes, and see if LM hashes show in those dumps. You can do this with variety of pwdump-like tools. I haven't done this in a while, but if memory serves, output file contains user name and id, along with LM and NTLM hashes. If LM hash isn't present, it will be ...



Top 50 recent answers are included