meta user
network profile
| bio | website | codingrobots.com |
|---|---|---|
| location | ||
| age | 30 | |
| visits | member for | 1 year, 10 months |
| seen | May 17 at 11:14 | |
| stats | profile views | 7 |
Programmer and founder at Coding Robots
|
Jan 26 |
revised |
Hashing passwords with a salt - why use different salt for everyone? added 95 characters in body |
|
Jan 26 |
comment |
Hashing passwords with a salt - why use different salt for everyone? In 2 you have a pretty big assumption. It's infeasible to bruteforce a long enough "shared salt" if it's random and the hash function is good. |
|
Jan 26 |
answered | Hashing passwords with a salt - why use different salt for everyone? |
|
Jan 25 |
comment |
Hashing passwords with a salt - why use different salt for everyone? Assume for a moment that we use a PRF with a single 32-byte randomly generated secret key in counter mode as PRNG for salt: PRFk(0) for the first user, PRFk(1) for the second user, etc. Take HMAC-SHA-256 as PRF. Rename secret key to "global salt". Replace counter with unique user id. Take scrypt as password stretching function. Is scrypt(password, HMAC-SHA-256(globalSalt, userId)) a sound password hashing scheme? |
|
Jan 11 |
revised |
Examples of applications that use the Schnorr digital signature? Remove word "Edit:" |
|
Jan 11 |
suggested | suggested edit on Examples of applications that use the Schnorr digital signature? |
|
Jan 10 |
awarded | Custodian |
|
Jan 10 |
reviewed | Edit suggested edit on Why do all SSH-RSA Keys begin with “AAAAB3NzaC1yc”? |
|
Jan 10 |
revised |
Why do all SSH-RSA Keys begin with “AAAAB3NzaC1yc”? start with a high-level explanation |
|
Jan 10 |
awarded | Enlightened |
|
Jan 9 |
awarded | Nice Answer |
|
Jan 8 |
awarded | Yearling |
|
Jan 8 |
revised |
Why do all SSH-RSA Keys begin with “AAAAB3NzaC1yc”? added 52 characters in body |
|
Jan 8 |
answered | Why do all SSH-RSA Keys begin with “AAAAB3NzaC1yc”? |
|
Jan 3 |
comment |
Needing to encrypt plain sight information @Andrew User1 can give away decrypted plaintext without revealing any keys anyway. Perhaps, you can tell us what kind of problem you're trying to solve? |
|
Jan 2 |
comment |
Needing to encrypt plain sight information Encrypt content with a randomly generated key. Encrypt this key for each user with a user-specific key. |
|
Jan 2 |
comment |
Needing to encrypt plain sight information Use TLS + server-side user authentication. |
|
Dec 29 |
awarded | Enthusiast |
|
Dec 27 |
comment |
Future-Proof Versioning and Validation @andrewcooke I see what you mean. If you're worried about this, don't tell users to update software, make "this is incorrect packet" the only kind of error. It hurts usability, though. |
|
Dec 27 |
comment |
Future-Proof Versioning and Validation "But that means that if someone maliciously alters the version then they can "trick" the code into aborting." If they are able to modify "packets", then they already can trick your code into aborting in any case by sending garbage or holding packets to make receiver believe that sender didn't send anything. |
