Hacker News Reader

Comment by coderdude | Hacker News Reader

I don't know if the creator is going to see these comments but lamernews.com goes to a GoDaddy parked domain page. Not sure if DNS changes just need to propagate or what.

View on HN

Hi, this is just the first public release. Hope to get more features inside and more testing before actually installing the first version into lamernews.com.

The code base got just a few days of after-work hacking, so probably this will take a few more days to be ready.

Thanks for the hint.

Just noticed you're using a single pass of SHA1 (salted) for password storage. Would you be opposed to a patch using a safer password storage mechanism? If not, I'll throw one your way in a couple hours.

if what you are thinking about is to use blowfish or other algorithm with a slow key scheduling step, what about if we just reiterate N times SHA1? Should be exactly as secure, like in:

SHA1(SHA1(SHA1(0|pass)|1)|2) and so forth.

This way there is no requirement for an additional library.

I would strongly recommend that rather than doing that, go with standard PBKDF2. In essence, HMAC(HMAC(HMAC(...(password)))) with a per-user salt. I generally recommend 10k+ rounds with PBKDF2 (each one is cheap). This wouldn't give you an additional dependency and is super easy to put in place -- I'll do it, if you want.

https://github.com/emerose/pbkdf2-ruby

If you concatenate your password and a salt, then iterate a cryptographic hash like SHA256 a few thousand times, this is almost exactly PBKDF1. It's a good, respectable password hashing scheme. The main advantage that PBKDF2 offers is the ability to produce arbitrary output sizes.

(The difference between this and PBKDF1 is that PBKDF1 requires using either MD2 or SHA1 as the hash function, and hasn't been updated to reflect the availability of SHA-256 and SHA-512.)

Note that PBKDF1 is exactly that, vanilla chaining of the same hash function. And AFAIK is not believed to have known attacks, with the only drawback being the fixed output size.

I guess that the xor approach used in PBKDF2 is useful since you want to compute T1, T2, T3 ..., Tc that are multiple output blocks all starting from the same input, so this gives more information to the attacker and the schema is designed to avoid showing some "state" that is possible to more easily analyze. Not sure, but the point is, I don't think PBKDF1 is unsafe either, and it is just chaining.

Why pass up an incredibly well testsed tool that will hands down be more secure than anything you can write on your own?

It's very much up for debate how much bcrypt, scrypt, and friends buy you over iterated HMACs like PBKDF2, which can be implemented in just a few lines of code. While I'd recommend the use of bcrypt or scrypt for most purposes, I personally have no qualms recommending something like PBKDF2 with a large number of iterations -- it's pretty damn sound. Iterated SHA1 isn't much worse than any of them, but there are a couple optimizations you can make while brute-forcing them, which you can't make with iterated HMACs, so I'd recommend going with that route.

daeken thanks for your knowledge. We should follow your example of understanding how things works instead of repeating "use bcrypt".

If iterated SHA1 and bcrypt are (all other things equal) equally secure, but you're more likely to mess up while implementing your own iterated SHA1, then bcrypt is more secure.

I agree, but we could do worse than to have "bcrypt" be the lay developer's default answer. All that is is annoying, whereas "secret salt construction using Whirlpool as the hash" or- whatever- craziness is actually dangerous.

Your code is neat. I don't care what hash you use. I'm just saying.

Use bcrypt, if for no other reason than that your code is likely to be forked by people who don't want to understand how things work.

Try

SHA256(SHA256(... SHA256(password + salt)))

With perhaps five thousand iterations of SHA256, if you really don't want to depend on bcrypt. Or just use bcrypt; it's a good library, and removes the temptation to get creative with password hashing.

Do not do this, repeated SHA'ing is not cryptographically secure: https://github.com/antirez/lamernews/pull/8#issuecomment-247...

Oh really? If you use SHA1 then the scheme I just described is a pretty well-established method called PBKDF1, specified in RFC2898:

http://tools.ietf.org/html/rfc2898#section-5.1

"PBKDF1 is recommended only for compatibility with existing applications since the keys it produces may not be large enough for some applications." — RFC 2898, September 2000

The keys it produces are big enough for this application. PBKDF2 can produce output keys of arbitrary size, which is why PBKDF1 got deprecated, but it's not always necessary.

I agree completely... I was hoping to see a live version. Live versions can help OSS spread and generate hacker interest.

However, it should be noted that I'm thankful that the author decided to share this.

Hi Jon! here it is almost the contrary, I wrote the code especially to run it as a real service. It is just that it needs a few more days.

But actually... I can just run it easily in a server of mine just to show it to you. Let's try to install it... just a moment.

Here we are: http://178.79.145.225:9999/

I'll leave it running for a few hours assuming it will not crash. It's very new code ;)

Readable fonts, thank you.

Here it is running on Cloud Foundry:

http://lamernews.cloudfoundry.com

Reply on news.ycombinator.com