Tag Info

Hot answers tagged

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.


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.


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


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.


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


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


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


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


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


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


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


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


4

There is no contradiction. Linus himself sais in that same talk: If I have those 20 bytes, I can download a git repository from a completely untrusted source and I can guarantee that they did not do anything bad to it. I'd interpret the "Git uses SHA-1 not for security" as "SHA-1 hasn't been added to git for security reasons, but for reliability ...


3

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


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


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


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


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


3

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


3

Unfortunately, the protection provided by using a different salt for each e-mail is designed to prevent exactly the same kind of queries that you need. So, if you need efficient queries, you should either use the same salt for all e-mails, or not use salt at all. Selecting a salt based on the hash of the e-mail is no more secure than using the same salt. To ...


3

Signed git tag is just a signed SHA1 checksum. Very simply said, every git commit is SHA1 checksum of the previous commit (which also contains SHA1 of its previous commit which also contains SHA1 checksum of its previous commit and so...). If you find a way, how to change something in a repository, keeping the SHA1 unchanged (you find a collision), then 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 ...


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/


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


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


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


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


2

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



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