New answers tagged

0

Others have noted the problems getting the card info to the site, but you must also think about how they handle that information internally. I once worked at a dotcom that stored credit card info in our database in plain text. Anyone with access to client info could see them. Lazy certification is only the tip of the iceberg, IMO.


14

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? IN NO WAY SHOULD YOU EVER USE THIS SITE FOR A CARD TRANSACTION The SSL issue is, as stated by others, relatively minor, however, using a SHA-1 hash ...


14

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


44

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


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


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


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.


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


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


1

Android requires app updates to be signed by the same key as the original app. So unless the developers themselves have been compromised, a MITM won't be able to update existing apps. Note that this process is completely unrelated to SSL certificates. App signing certificates are self signed and don't rely on certificate authorities for trust. It sounds ...


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


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.


-1

Here is the comparison between MD5 and SHA1. You can get a clear idea about which one is better.


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


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


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


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


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


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


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


1

This method should have following properties: Probability of false positives can be made as small as desired Server learns only the (approximate) number of items on each person's phone book, but not numbers themselves and cannot brute-force them Client-side brute-force attacks are impossible, as server can enforce policies against them Phones do not learn ...


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


0

Why hash them? Why not encrypt instead, and send them to your own server. That way neither client device has to have access to each other's contacts, and the server does most of the work. This does introduce a single point of failure though, the server. If it was compromised, the attackers could potentially access all numbers. This could be controlled if ...


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


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


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


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


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


1

Given the thin details in the story it's hard to be sure, but the simplest explanation is the credentials were not encrypted when the hacker made a copy. The passwords might have been encrypted in a database, but many so-called 'transparent' database encryption schemes serve only to protect the database file from being copied and reused; they ...


1

Passwords should not be encrypted, they should be hashed. Encryption can be easily reversed if you have the key - and an attacker who has managed to steal the whole database probably has stolen the key as well. A hash can not be easily reversed. When someone attempts to login, the server does not decrypt the stored password. Instead it hashes the provided ...


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


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


0

You cannot sign large data blocks using any of the commonly used asymmetric signature schemes. For signing larger data, you would have to split it in blocks and sign, but if you just do that without nonces/padding/etc, it is very insecure. If you use some high-level library for your signatures, it most likely already hashes the data you give it to sign so ...


1

In your specific use case, this assertion is faulty: ... suggested that a small digest is susceptible to rainbow tables and other attacks ... A rainbow table is only a lookup table of pre-computed digest values. Think of your use of a hash like the index at the end of a book, telling you what page number to read to find the real context containing ...


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


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


3

The salt in a password just needs to be random enough so that its more or less evenly distributed. The salt is just used to make attacks with precomputed password hashes or rainbow tables infeasible by increasing the needed memory. Thus there is no need for a cryptographically secure random generator. This means that the implementation is secure enough in ...



Top 50 recent answers are included