Hacker News Reader

Comment by timclark | Hacker News Reader

Why would I use Noir instead of compojure or ring + moustache?

Zak's characterization is basically correct. Noir isn't really a replacement for those things, more of an abstraction over them. It was born out of seeing how a real web-app evolved and what was missing from the ring/compojure/hiccup stack as I built http://www.typewire.io. Also, as I mentioned in one of the other comments, I hope that it will serve as the single "package" to start with web development in Clojure, instead of having to try and cobble it together from the pieces that are out there now. By controlling all of it, I can create a much more cohesive and well defined story for helping people get started. I can also share what I've learned about maintaining websites in Clojure and hopefully encourage patterns that avoid some of the pits I fell into.

I'm encouraged that Noir builds on top of existing tools. It indicates that our current set of web libraries is flexible and modular enough to act as a good foundation for more sophisticated frameworks.

It looks like Noir uses a custom "lein run" command to start the server. Have you considered using the lein-ring plugin, instead?

I also wonder if this isn't a result of using a Lisp. In Node.js you see an absurd proliferation of libraries that do essentially the same thing but provide slightly different syntax. In Lisp you can reuse an existing library, provide your own surface syntax and not incur any overhead.

I've found that this is a really nice "feature" of Clojure, and maybe other Lisps. Most libraries are very small and tend to all speak in terms of the same de facto standard interfaces (functions, seqs, hash maps, vectors, etc.) so they can be easily composed. Trying to fit together Java or C# libraries like this is basically impossible without some mediating standard base classes or interfaces.

Not about Clojure, and has probaby been posted before, but: http://gbracha.blogspot.com/2011/06/types-are-anti-modular.h...

I did originally, but I wanted more control on how middleware gets wrapped around the app, as well as the ability to have dev and production "modes". Each of these adjusts what middleware goes into the stack and how it reacts.

Ah, I see. Have you considered writing a "lein noir server" command that starts the server? That way people could use the same `:ring {:handler blah}` syntax in their project.clj file, and have their application work with lein-ring and other plugins such as lein-beanstalk.

Thanks for this - it has just worked as a good start point for me. As a grumpy person who doesn't like searching for libraries, these "low barrier to entry" and "meta-library" ideas make me less grumpy.

It looks like Noir is a library of convenience functions built on top of Compojure, Ring and Hiccup. Some of it looks useful, though the fact that it uses SHA1 to hash passwords is not a good sign.

An oversight on my part :) Luckily, that is an exceptionally easy thing to fix.

Edit: and now it is :D

Still some nits -

* SHA-x is not an "encryption" algorithm, it's merely a cryptographically secure, one-way hash. The function name and the documentation are thus misleading.

* You shouldn't use SHA-x or MD5, etc. for password hashing anyway, because they are just way too fast! You should use BCrypt for password hashing.

I can submit patches if you wish :)

Absolutely! I don't claim to be an encryption expert, by any means. :)

I am no crypto expert either, but here is your patch - https://github.com/ghoseb/noir/commit/f814ea9d1bc7470197eb73... (pull request already sent).

Noir looks very good. Keep up the good work and let me know if you need any help ;)

Just out of interest, what do you mean by 'way too fast'? I would think that having a fast hash would be a good thing. Or is it because an attacker can generate hashes for some dictionary very fast? Isn't this why you'd use a salt as well?

Sorry if these seem like dumb questions, just trying to learn.

Hashing algorithms like SHA-256 have a very interesting property, they are designed to be extremely fast (even with large amounts of data). That lets you generate millions of hashes per second on any modern CPU (much faster with GPUs). Salting doesn't help much because if your DB is compromised, you are still open to brute force or dictionary attacks.

BCrypt is a very good algorithm for hashing passwords because it's very slow (compared to SHA-x) and thus are extremely time consuming for an attacker. BCrypt also allows to incorporate a "work-factor" which makes the hashing even slower; that allows us to choose a higher work factor when more powerful computers become commonplace.

There are a lot of articles online that discuss this subject.

The faster you hash, the faster I can run a brute force attack on your password form.

No, this is technically wrong. There are better ways of stopping a brute-force attack on a password form, such as attack detection, and black-lists. If you rely on a computational delay to slow attackers down on your servers, you will merely open yourself to a simpler DDOS attack. The purpose of a computationally expensive hashing algorithm is that it prevents brute-force attacks against a stolen copy of your password database, where the attacker no longer has to deal with your other defenses.

Quick question, if you have the db but not the salt, does the speed of the hashing algorithm still matter?

The salt is usually in the db as you should have a different salt per password. The purpose of the salt is to add some complexity so that each password is in fact hashed by a slightly different algorithm (in order to defeat pre-computation based attacks.) If the attacker does not know that salt, then he does not know the full hash algorithm and cannot brute-force the password. So technically no, I don't think so. However, if the attacker can get your password db he can also get your salt db so I wouldn't rely on this by any means.

Disclaimer: I'm absolutely not a security professional.

It wouldn't, but it's a Bad Plan not to have per-user salt, so the circumstances where you'd have the passwords but not the salts that go with them would be... odd.

Thanks to you and astine, I just learned today about per-user salts. I thought that you only needed a site-wide salt and after reading on the topic, I now understand why it's better to have a per-user salt stored in the db.

I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)

See http://codahale.com/how-to-safely-store-a-password/

Reply on news.ycombinator.com