19,309 reputation
23291
bio website
location Brooklyn, NY
age 33
visits member for 3 years, 2 months
seen 26 mins ago
Good Morning how are you, I'm dr jimbob
I'm interested in things.
I'm not a real dr,
But I am a real jim bob.

Have a PhD in Experimental High-Energy Physics, but left academia in mid-2010 to program professionally.

Mostly program/script in python, django, and jquery these days doing mostly web apps.

Also have experience programming in C, C++, java, haskell, php, and (bash) shell more in the past.

Linux as primary OS since 1999, ubuntu user since 2005 (Hoary).


Dec
19
comment Is my developer's home-brew password security right or wrong, and why?
@Polynomial - I assume the right variables are being stored in the database. He never explicitly said that $hash is stored in the DB, so how could the code work? I assume before consideration of being used that it will be functional -- e.g., there was one successful login. Then either $crypt = crypt($user.$time.$rand) is stored in the DB or $user, $time, $rand are stored in the DB. The part I changed was (a) reference to crypt($pass) which wasn't in his code, and (b) calling his salt bad or broken as it has a very high probability of uniqueness.
Dec
19
comment Is my developer's home-brew password security right or wrong, and why?
Edited slightly. Note he doesn't take the crypt of the password, so his crypt=crypt(user+random+timestamp) is a salt; and while its overly-complicated its also unique. His algorithm is sha1(salt+dumb_permutation(md5(pass))). I agree dumb_permutation has no purpose (but doesn't make it weaker). Now salt=crypt(user+random+timestamp) is probably stored in the db (or he stupidly stores user, random, timestamp in the db and regenerates at each login though this doesn't make brute forcing more difficult). Also the last comment is unjustified; he's merely calling the function he defined.
Dec
19
comment Is my developer's home-brew password security right or wrong, and why?
@bradley.ayers - I understand the difference (ciphers are used for encryption; hashing is not encryption as its not reversible.) The meme image first used the word "cipher", and I didn't criticize Rory as cryptographic hash function like MD5 and SHA1 are based on algorithms similar to block ciphers: en.wikipedia.org/wiki/… However, Dave didn't create his own cipher/hash functions or anything similar. He merely did a dumb permutation of an MD5 at one step of a weak hashing scheme (sha1(salt+md5(pw)).
Dec
19
revised Is my developer's home-brew password security right or wrong, and why?
He applies crypt(user+random+time) to generate a salt (he must store the crypt, or random, time) in the db. He does not apply crypt of the password.
Dec
19
comment Is my developer's home-brew password security right or wrong, and why?
For more on collision attacks vs pre-image attacks inspired by the old form of this question, see the second half of my answer.
Dec
19
awarded  Good Answer
Dec
19
revised Is my developer's home-brew password security right or wrong, and why?
added 867 characters in body
Dec
19
comment Is my developer's home-brew password security right or wrong, and why?
Funny and agree with the sentiment, but its irrelevant as he didn't write his own cipher. He took existing crypto-hash functions MD5 and SHA1 along with custom permutation function dumb_perm (dumb_perm('00112233445566778899aabbccddeeff') goes to 'ccddeeff8899aabb0011223344556677'), so hash = SHA1(salt++dumb_perm(MD5(pw))) and created their salt in an overly complicated manner. While they've increased their maintenance costs for no gain in security, they are not creating their own cipher--the flaw is that simple hashes are too quick nowadays, so key-strengthening is necessary.
Dec
18
awarded  Nice Answer
Dec
18
revised Is my developer's home-brew password security right or wrong, and why?
added 985 characters in body
Dec
18
revised Is my developer's home-brew password security right or wrong, and why?
added 985 characters in body
Dec
18
revised Is my developer's home-brew password security right or wrong, and why?
added 98 characters in body
Dec
18
revised Is my developer's home-brew password security right or wrong, and why?
added 138 characters in body
Dec
18
revised Is my developer's home-brew password security right or wrong, and why?
added 2463 characters in body
Dec
18
comment Is my developer's home-brew password security right or wrong, and why?
First, SHA1 is 160 bits. Second, being broken for collision attacks (2^(n/2) to brute force) doesn't matter the slightest in the domain of cracking a hashed password (where you worry about (first) pre-image attacks - 2^n to brute force); see: en.wikipedia.org/wiki/Preimage_attack . For crypto-signatures a collision broken hash (and SHA1 is broken in 2^61 time) can't be used (as signed messages could be altered). (Though the simplicity and speed of MD5 and the existence of large rainbow tables does mean its bad for passwords.) Agree with your arguments for bcrypt though.
Dec
18
answered Is my developer's home-brew password security right or wrong, and why?
Dec
11
comment How do I prevent this type of SQL injection attack?
@Polynomial - I recommended bound parameters and in practice never encountered the situation where the pre-planned execution plan create a bottleneck that had to be fixed. Yes, my regex wouldn't let you search for J.J., Green-Ellis, O'Neill or Erdős and coupled with bad SQL strings could fail (SELECT * from mytable where name={user_input}; with no quotes around '{user_input}'). But a simple let's replace ' with \' may fail for complicated reasons (e.g., unicode characters got mapped to ' or you didn't map ` to \`) or they found some way to bypass your input sanitation.
Dec
11
comment How do I prevent this type of SQL injection attack?
Bound parameters aka parameterized query is the optimal solution. Its risky to trust any input sanitation you wrote yourself, as that's rolling your own security which is a bad idea and a clever attacker may be able to get through. Also bound parameters generally run faster, unless some queries benefit greatly from a different execution plan that a smart DB can figure out without bound parameters [[1]](use-the-index-luke.com/sql/where-clause/bind-parameters). If thats the case, make sure your input sanitation just whitelists safe input; e.g., filters out chars not in [A-Za-z0-9 ].
Nov
26
comment How do you explain the necessity of “nuke it from orbit” to management and users?
@MartinSchröder - I agree that pdfs (like *.doc) are dangerous as they aren't simple plaintext, but will often auto-execute embedded scripts. I disagree with images which will generally be safe when viewed through mature viewers. In principle, image viewers could be susceptible to buffer-overflow attacks, but only if poorly written (e.g., unsafe language with unsafe libraries never doing bounds checking). I'll browse the web and view whatever images are presented with no danger of viruses (unlike pdf/doc).
Nov
26
awarded  Nice Question