Hot answers tagged

71

It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on. The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm. What does that mean? It means the connection is encrypted and a passive eavesdropper can still not listen in. But a ...


71

Yes, you should hash your passwords. Storing passwords in plaintext is not acceptable. No, it does not affect the amount of traffic your site require. The hashing should be done server side, so it does not affect what is transmitten from the client. Hashing the passwords protect them from theft once they are stored in your database. To protect them from ...


25

bcrypt would be a somewhat better approach because it is designed to be (programmably) slow. Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank ...


23

As others have said, technically the risk is small for a MiM attack. However this has a larger problem and implication. Should I go ahead and enter my card details and pay for something on this site? NO, YOU SHOULD NOT USE THIS SITE FOR A CARD TRANSACTION The SSL issue is, as stated by others, relatively minor, however, using a SHA-1 hash means two ...


22

Encryption vs. Hashing Nobody really "encrypts" a password, although you could... but you'd be encrypting it with another password, and you would need that password to decrypt the first password. When it comes to passwords, we normally hash them. Hashing is simply one-way. You cannot get the string back, you can only check to see if a string validates ...


17

There are potentially other privacy issues you're not considering yet. By design your app makes it easy to see who is connected to a certain target. So an attacker creates one contact on their phone (the activist/informant/terrorist/victim they are interested in) and then connects to many other users through your app, to create a list of the target's ...


16

It means that the certificate used by the site is using an outdated signature algorithm to confirm the certificate identity. Google has been aggressively targeting SHA-1 signatures for site certificates for a couple of years, since there are some theoretical attacks which could result in a fraudulent certificate having a valid signature, although there has ...


11

A hash is an irreversible process: one function, 'hash' which cannot be "reversed". Once you have a hash, you can only guess the original password via a brute force attack, which involves hashing a variety of possible passwords until you end up with the same hash value, which indicates that the password you guessed is the same as the original. Encryption ...


11

Yes, it is (a bit) flawed. The problem is that the space is too small, so even with the multiple rounds and salts, it's relatively easy to bruteforce. Open Whisper Systems had a witty system where they provided an encrypted bloom filter that can be queried locally using blind signatures. They explain the process (as well as providing a good discussion of ...


6

How can we do this in a cryptographically secure way and respecting the users' privacy (i.e. without sharing the numbers in plain-text between them or with a server)? tldr: You can't. Hashing is great for certain uses, but this is probably not one of them. The reason is that an attacker would know that there are only 10 billion possibilities (for ...


6

Firstly terminology, SHA-512 is a hashing algorithm not an encryption algorithm, so it makes not sense to talk about "decrypting a SHA-512 hash". As your link states you are trying to find a collision e.g. an input that gives the same value as a known hash. If you have an unknown, large, random input this becomes an exhaustive search such as described first ...


5

OK, so the first issue is: do you need these rolls to be reproducible and predictable? That is, do you need to be able to fast-forward to the 10000th roll or rewind to the 20th, and get the same result? If you don't need that feature, then why not use a cryptographically secure random number generator instead? This way, neither you nor an attacker can ...


5

Let's do some tests! I started with a naive bash implementation, and calculated 10k numbers in 33 seconds: #!/bin/bash phone="2125551212" salt="abcdefghijklmnopqrstuvwxyz" shasalt() { echo "$* $phone $salt" | sha512sum; } for f in {1..10000} do shasalt $(shasalt $(shasalt)) >/dev/null # or write to a file... ((phone++)) done echo ...


5

The reason for key strengthening is that passwords don't have as much entropy as is expected for the key. The time it takes to break a key is proportional to the number of possible keys. Strengthening algorithms used on passwords compensate for the poor entropy by increasing the proportionality constant. But the gap is so large that strengthening cannot ...


4

You have got that wrong, at least the encryption. Asymmetric Encryption is done using public key of the receiver. Therefore it provides Secrecy (nobody without private key can not read the message). But it does not provide Integrity -- anyone can encrypt any message and send it to you with your public key. Wikipedia is a good friend: Digital signature ...


4

Yes. Salt is used to prevent precomputation attacks, but random 256 bit strings are too large for precomputation. Slow hash functions with many iterations are meant to slow down dictionary attacks, but random 256 bit strings are too big for a dictionary or for exhaustive testing. So a single SHA256 hash is secure for long, cryptographically secure random ...


4

Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to ...


4

Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem. Additionally, since you have control over the ...


3

You can use bCrypt. The simple solution is sending your user a an Id and the Token: https://example.com/pwdReset?resetId=123&resetKey=[your long randomly generated key] You can lookup the hash using the id (just like you would use the username to lookup the user's password hash).


3

With Isemis mention of "probability of false positives" I thought about Zero-knowledge proof. This answer makes no claims to be secure as it was never reviewed, so others should review and comment it. I am no professional security expert either and I didn't have the time to make sure the low number of possible phone numbers might be a problem. User A and ...


3

I want to make a few points in addition to @NeilSmithline's excellent answer. Taking a 256-bit random value and hashing it with SHA-256, the output will still have (roughly) 256 bits of entropy. I say "roughly" because it's an open problem whether SHA256 actually maps to every possible string on 256 bits - but for all practical purposes, it's close enough. ...


2

In practice it literally doesn't matter. If your key size is 512-bit (I'm not sure what cipher you're using, as none that I'm aware of use 512-bit keys, but whatever) then you've got two scenarios: In a small digest you've got so many collisions that discovering the original key by looking for matching values will give you a silly number of results. Not ...


2

For clarity to other readers, password-based key derivation is hashing, not encryption. It's designed to produce encryption keys from passwords, not encrypt passwords. You would hash the password with the function (which I will refer to as the PBKDF) and then encrypt the data with the resulting key. A strong password hashed with a strong algorithm would ...


2

For encrypting data, it's generally recommended to store a random key and encrypt this with the appropriately salted password. This means that if/when the user changes their password, you only need to decrypt and re-encrypt their key, and not all their data.


2

Yes, there are several requirements for an iterative hash function: It should not be possible to do any precomputation, such as using rainbow tables. The implementation should avoid running into cycles or fixed points in the hash function. The implementation should be as fast as possible, because that is what the attacker would use. Especially on the ...


2

JDBC is a Java API. It uses JDBC database drivers to actually communicate with database servers. These drivers may or may not support TLS. The PostgreSQL JDBC driver supports TLS: https://jdbc.postgresql.org/documentation/94/ssl.html So, it would connect to the database server using TLS, then send the username and password to authenticate. You would not ...


2

Say I am using SHA-1 which outputs 160 characters string, and my input string is 161 characters, so does that mean each of my 161 character message has at most unlimited collisions and at least 10 collisions/pre-images each of 161 characters. Is my understanding correct? No. First it cannot have unlimited collisions since the number of messages with ...


2

This would make the password LESS secure. Consider a 16-character password made up of a sequence of randomly chosen letters, numbers, and symbols. By itself, this password is basically "uncrackable" for all intents and purposes, even if your password database is leaked, assuming you hash the password. You could probably even use something stupid like MD5 ...


2

Field Password and "X" contain a part of the hashed function most likely a split of the first Y characters in the password field, and the rest in the "X" Field. Combine and check if correct. Is there anything wrong with this approach? I surely feel that this would be a problem for any attacker. Yes, this severely weakens the hash security. Instead ...


1

As you already determined correctly multiple images resulting in the same hash must be possible. The argumentation is simple: there is a limited number of hashes and an unlimited number of images which means that there must be multiple images resulting in the same hash.



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