Reputation
2,962
Top tag
Next privilege 3,000 Rep.
Cast close & reopen votes
Badges
1 11 19
Newest
 Yearling
Impact
~223k people reached

  • 0 posts edited
  • 0 helpful flags
  • 283 votes cast
Apr
25
awarded  Necromancer
Apr
25
comment How to apply a pepper correctly to bcrypt?
@Powerman - There is a better way to add a server side key to the hash, i updated my answer to point it out. Doing it this way you cannot decrease security, because in the worst case an attacker just gets the original hashes. I wrote a tutorial about safely storing passwords, where i tried to describe it more indepth.
Apr
25
revised How to apply a pepper correctly to bcrypt?
Added note about using encryption instead of a pepper.
Mar
30
answered HTTP/HTTPS on the same site
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
23
revised Why is it not standard practice to run password-based KDF's client-side?
Explained reason why a non-iterated hash can be used.
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
revised Why is it not standard practice to run password-based KDF's client-side?
deleted 43 characters in body
Mar
21
revised Why is it not standard practice to run password-based KDF's client-side?
added 19 characters in body
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
21
answered Why is it not standard practice to run password-based KDF's client-side?
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.
Mar
11
awarded  Yearling
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.
Jan
31
answered Do you need to use the same number of rounds for everyone with bcrypt?
Dec
21
awarded  Nice Answer
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?
Dec
16
revised Can't brute force password cracking somehow be throttled?
Sorry, wrong word