Reputation
3,079
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
9 21
Newest
 Yearling
Impact
~91k people reached

  • 0 posts edited
  • 31 helpful flags
  • 332 votes cast
Aug
26
comment Can simply decompressing a JPEG image trigger an exploit?
The point of an infected image exploiting a JPEG decompressor is that there is no interaction required. If you have a buggy JPEG implementation, as in the GDI+ example provided by @gowenfawr, you can be compromised by simply viewing a webpage or email. Such images can be served by an advertising script on even trustworthy sites. That is far more interesting and worrisome than JPEG being used as an innocuous-seeming communication mechanism for a preexisting infection.
Aug
26
comment Can simply decompressing a JPEG image trigger an exploit?
While the technique is possible against a buggy JPEG decoder, this doesn't appear to be an example of such. This is simply encoding a configuration file in a JPEG to hide updates to an existing infection. OP appears to be asking about JPEG images as a vector for transmitting new infections.
Aug
25
comment “If encryption has not been implemented, a comparable alternative has been implemented”
This is probably something you should discuss with your HIPAA auditor.
Aug
22
awarded  Yearling
Aug
13
comment Double hashing using a relatively new hash and a old, tested one
The short answer is that theoretically, this is no weaker than the strongest of the two hashes. The caveats are that in reality, a particularly bad implementation of the inner KDF could leak enough information to an attacker through side channels to break the construction, although this is unlikely in practice. Additionally, every line of crypto glue you write is an opportunity to introduce a security flaw. That said, I personally would simply either pick one of bcrypt or scrypt and move on to solving more pressing problems — the gain of using both is overwhelmingly likely to be zero.
Aug
13
comment Double hashing using a relatively new hash and a old, tested one
@RensvanderHeijden Also, a KDF can be used to derive purpose-specific subkeys from a single master key (for instance, HKDF).
Aug
9
comment Not storing the salt? Is that an option?
True! Upvoted your comment.
Aug
7
comment Not storing the salt? Is that an option?
@LieRyan Your statement is incorrect, full stop. Salts do not require any entropy whatsoever — in attack scenarios, it is assumed that the value is completely known to an attacker. The purpose of a salt is to ensure that work from an attempt to guess one hash cannot be applied to others. To succeed in this, its one and only requirement is to be unique.
Aug
7
comment Not storing the salt? Is that an option?
I really don't like the use of the word pepper here. "Pepper" has no agreed-upon meaning in cryptographic contexts, and has been used to indicate a static part of a salt, a secret key used for the HMAC of a password prior to hashing, and for unknown components of a salt. Given that there is no standardized use of the term (or even widespread adoption of the practices each of its meanings refers to!), I don't believe we should promote its use.
Aug
7
answered Not storing the salt? Is that an option?
Aug
5
comment Why does gpg use /dev/urandom
Hell, read the scathing comments by DJB, Thomas Pornin, and Thomas Ptacek on the debate (ironically, one of these people has already answered your question in this exact thread).
Aug
5
comment Why does gpg use /dev/urandom
He answered the first part, which is: No, using /dev/urandom does not in any plausible scenario result in the generation of weak GPG keys. In fact, systems like OS X and FreeBSD have gone as far as completely doing away with the distinction between either, where /dev/random is now just a symlink to /dev/urandom.
Jul
20
comment Double encryption with home brew algorithm
@PatrickM Read up about side channel attacks. A poorly-implemented transformation can leak information about the plaintext, where the attacker doesn't even need to look at the ciphertext. For instance, if you use the plaintext as a loop bound, the difference in time it takes to perform the transformation on different plaintexts can be used by an attacker to learn the plaintext.
Jul
18
comment Double encryption with home brew algorithm
AES(k_1, HB(k_2, pt)) can easily be completely broken if HB is designed by an amateur. For example, if HB uses loop bounds or lookup tables based on the plaintext, it can trivially leak enough information for an attacker to recover it without having to break AES. Leave cryptography to professional cryptographers.
Jul
10
comment Password rules: Should I disallow “leetspeak” dictionary passwords like XKCD's Tr0ub4dor&3
I'd also suggest blocking the 1,000 or so most common passwords.
Jul
10
comment User account password hashing
1. No, the SHA-2 family of functions are not suitable as password hashes. Just use bcrypt. 2. No, the client-side hash effectively becomes "the password" and now you're storing "the password" in plaintext. 3. No, passwords should be hashed, not reversibly encrypted.
Jul
3
comment Using UUIDs for non-guessable URLs
If you're using 16 bytes (128 bits) of cryptographically secure randomness, it being "a UUID" is simply conceptual and irrelevant. This is a simple application of the birthday problem. The short answer is that an attacker will never guess one of these URLs, unless you generate a truly astronomical number of them.
Jul
3
comment Using UUIDs for non-guessable URLs
Unless _uuid_generate_random is set. More importantly, the documentation does not guarantee that the underlying implementation is cryptographically random, so even any future update could easily use something worse.
Jul
3
comment Using UUIDs for non-guessable URLs
Don't use non-cryptographic sources of "randomness" for things that shouldn't be guessable. Just use os.urandom and convert it to base64.
Jul
1
comment Can a salt maintain pseudo-randomness after being modified?
There's no need to "derive" a random salt from your already-random salt. Just encode it directly as hex. That said, cryptographic hashes such as the ones offered by hashlib are unsuitable to use for passwords. Just use bcrypt.