1,307 reputation
1412
bio website martinstoeckli.ch
location Switzerland
age 41
visits member for 2 years, 1 month
seen 44 mins ago

I belong to the lucky people, who can combine job and hobby, in my case writing software. Coming from the Delphi world, i'm working more and more with CSharp and use PHP for my spare time project, an internet lost-and-found office.

// Don't tell people not do something, explain the reasons and let them think for themselves.


Mar
26
comment When and where do I hash a password?
The answer of this question Why is it not standard practice to run password-based KDF's client-side also explains pros and cons of client side hashing.
Mar
22
comment Why use PBKDF2 over multiple iterations of a another cryptographic hash function?
Could you explain why you think that PBKDF2 is superior to BCrypt?
Mar
21
comment Why is it not standard practice to run password-based KDF's client-side?
@xkcd - What Levi tried to explain is, that it is absolutely safe to store an unsalted non interated hash, if the "password" is strong enough. Salting and key-stretching is necessary, because people choose relatively weak passwords, which they can remenber. The output of a PBKDF2 on the other side is a very strong "password", and can be hashed with a hash algorithm like SHA512 even without a salt.
Mar
21
comment Why is it not standard practice to run password-based KDF's client-side?
@xkcd - If you had calculated a server side hash, then even with the hash-values (from SQL-injection for example) you could not login. If you store the client side hash directly, you can login as soon as you know the stored hash-values.
Mar
12
comment Relationship of password strength and key strength
@user1066616 - Actually a key derrived from a password, cannot become more secure than the original password (same number of tries). As far as i know, the only advantage to generate a key is, that a slow key-derivation function will slow down brute-forcing a lot.
Feb
2
comment Do you need to use the same number of rounds for everyone with bcrypt?
@user3100783 - Theoretically it would be ok to calculate the BCrypt hash client side, and only do a fast SHA512 on server side. This works, because the calculated BCrypt hash is a very strong "password", and for strong passwords a simple hash is enough. The problem is, that JavaScript is a slow language for this kind of calculation, so you will probably do fewer rounds and that weakens the security.
Jan
31
comment Do you need to use the same number of rounds for everyone with bcrypt?
@CodesInChaos - You could at least split the work on client and server, so the client could do the heavy work, while the server could hash with a "lite" algorithm before storing in the database. The question is whether you can rely on JavaScript at client side, but today probably we can.
Dec
20
comment For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used?
@AliAhmad - I don't get it, every encrytion scheme should depend on a key, the key is the only thing that must remain secret. Did i miss something?
Nov
12
comment Is it useful to protect hashed password with encryption?
@oleksii - Not really, the salt prevents using rainbow-tables and with unique salts, each password has to be brute-forced separately. Against brute-forcing a single password, a salt will not help. Today you can calculate several Giga hashes per second with common hardware, that's why you need a slow algorithm. Even with a slow algorithm you can test for the most used passwords, this is kind of a dictionary attack. I would invite you to have a look at my tutorial about secure password storing.
Oct
25
comment Is this site vulnerable to sql injection?
Sure, error messages can give hints about the system in use, that's why they should never reach the page viewed by the user, instead a general message should be displayed. But this doesn't mean your page is vulnerable to SQL-injection.
Oct
25
comment Is this site vulnerable to sql injection?
Such an error message should not be displayed on a productive website, but why do you think it has something to do with SQL-injection?
Oct
15
comment comparing password hashing algorithms - PoC ideas?
The number of hashes calculated by oclHashcat with common hardware are very convincing. For plain SHA-256 this is more than 1 Giga hashes per second, compared with an english dictionary containing about 150000 words... well that makes a fraction of a millisecond.
Oct
11
comment Does using Bcrypt to encrypt credit card numbers satisfy PCI compliance?
@jpkrohling - You should think of the salt as a known value, it is not a secret. It will not make it harder to brute-force a single value, but can prevent an attacker to build a rainbow-table to get all numbers at once.
Oct
10
comment Does using Bcrypt to encrypt credit card numbers satisfy PCI compliance?
Usually if you have need to store a credit card number, you want to be able to decrypt it later, so you can use it again for payment. What reason do you have to store only a hash of the number, which is a one-way function and cannot be decrypted?
Sep
4
comment Do salts have to be random, or just unique and unknown?
@MisterMelancholy - You use a slow hash like BCrypt and a pepper, exactly for the case a hacker gets access to your database or server. If the hash function is slow, an attacker can calculate e.g. only 1 hash instead of 8 Giga hashes. The pepper requires the attacker to have privileges on the server, what is more difficult than just having read access to the database.
Sep
4
comment Do salts have to be random, or just unique and unknown?
@MisterMelancholy - I updated my answer accordingly.
Sep
1
comment Do salts have to be random, or just unique and unknown?
@demize - Well that's the actual question, does it really introduce a new attack vector and how? The userid would make the salt unique, the domainname would make it globally unique, and the password would make it unpredictable. It is possible to regenerate it, and when the password changes, it would result in a different salt.
Sep
1
comment Do salts have to be random, or just unique and unknown?
@Griffin - There would be no need to store the plain text password, because when you verify the password all necessary information is available, the userid, the constant text and the just entered password.
Sep
1
comment Do salts have to be random, or just unique and unknown?
@Griffin - I think the OP's question actually is: "Can storing a salt be avoided completely, derriving the salt from userid, constant text, and the password itself".
Sep
1
comment Do salts have to be random, or just unique and unknown?
@MisterMelancholy - You cannot rehash the password when updating the email address. To create the new password-hash you need the email and the original password, but at this moment you know only the email and the hash of the original password.