OSDev.org

Hello there. I'm not quite sure if this is the proper place to ask for such a thing but I figured I'd give it a shot.

Basically, I've made an authentication library for use in ASP.Net. Why? Because I think writing 200 lines of code to get Forms Authentication to work on your own database is stupid. Also, Forms Auth is the only real authentication method I can find with everyone quoting "you can use Forms Authentication, or you can roll your own." Well, everyone knows how problematic rolling your own can be. So I've rolled my own, checked it a billion times and I think it's pretty damn secure. So I'd like to offer an alternative.

What makes it worth using?
It's fast: Requires only 1 database hit on all operations except for adding a user. Requires computing just 2 hashes for most operations as well. Also, there is no Session to worry about. This uses no persistant medium for storing sessions, neither database nor memory. This also makes it capable of working in a web cluster environment, out of the box. It's what I like to call "stateless"
It's secure: By default, all passwords are salted and hashed in SHA256.
It's easy: Configuration can be done in about 4 lines of code. If you want to use your own database layout(ie, creating your own UserStore class), then it doesn't require a lot, depending on your database. My simple in-memory list UserStore uses just about 60 lines of code. And it's trivial code to write, at that. A MongoDB interface used about 70 or 80. Most permissions can be validated with 1 line of code.
It's standard compliant: Unlike Forms Authentication, it will rightfully give you 401 and 403 errors, rather than redirects.

I've designed it so that even if your database was leaked and someone knew all of your password hashes, the passwords would be safe, and they would still be incapable of forging a working login cookie.

How does it work? Basically, a UniqueHash is used that is kept a secret. This UniqueHash goes into the creation of both passwords and login cookies. The only way someone could forge a login cookie is by knowing this value. And the only way they can know the value is by reading either your source code or your web.config.


Anyway beta-testing. I need beta testers for this. This IS a commercial project. If you are interested in beta testing, either post here or PM me with a bit about yourself and how you will beta test it(ie, are you going to implement it in your blog? Or whatever). After the end of the beta, testers who sent me feedback will get a non-expiring single-site license. Those that sent me amazing feedback will get a non-expiring multi-site license.

A demo is available at http://fscauth-demo.lastyearswishes.com (note, when registering you can see the hashes generated for the password)

I am still actively developing it, and it still has a few rough edges that I'm working out. And documentation is still being created, but I'm working rapidly on it and trying to gather up some beta testers so when I am ready in a couple of weeks, I can continue with the beta process in a fairly quick fashion.

Also, a bit more information can be had at my blog: http://lastyearswishes.com/blog/view/4d ... 4ec6d6a37d

berkus wrote:

It's secure: By default, all passwords are salted and hashed in SHA256.

Not
secure.

End of story.

It's possible to configure to use bcrypt, or use multiple iterations of a chosen hash algorithm. I decided that SHA256 is secure enough, and most people agree. And it should be noted that I do hash a unique salt(along with the server-wide unique hash) for each user password.

earlz wrote:It's possible to configure to use bcrypt, or use multiple iterations of a chosen hash algorithm. I decided that SHA256 is secure enough, and most people agree. And it should be noted that I do hash a unique salt(along with the server-wide unique hash) for each user password.

You have decided. What are your formal security qualifications? What peer review has your cryptosystem (And yes, it is a cryptosystem) had?

Smart developers leave cryptography up to people who understand it. Hell, to quote one of those articles:

Matassano Security wrote:No, really. Use someone else’s password system. Don’t build your own.
Most of the industry’s worst security problems (like the famously bad LANMAN hash) happened because smart developers approached security code the same way they did the rest of their code. The difference between security code and application code is, when application code fails, you find out right away. When security code fails, you find out 4 years from now, when a DVD with all your customer’s credit card and CVV2 information starts circulating in Estonia.

I mean, really, why would you not outsource your code? Its less work for you, and you can let people who are experts at it do it.

Smart people understand when they're out of their depth and delegate to people who truly understand what they're dealing with. Dumb people overestimate their own capabilities (because they don't truly understand as much as they think they do).

Seconded. Cryptography is a highly involved academic subject. And even if you use ready-made algorithms, the way you implement and combine them into a system is important. If you have any chance to fall back to ready-made framework code, do so.

A good friend of mine works in exactly that field - security systems and how to break them. The ease with which he can pick apart your average homegrown system - and quite a few professional ones, including stuff like iPhones and Blackberrys - is staggering. The chances to keep such an individual out of your system is slim if you aren't a full-time professional with years of experience.

This couldn't be more well timed...

Bruce Schneier wrote:Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

What's with all the bashing, folks? Good cryptography is hard stuff and I'm by no means an expert but if no one attempts to implement it, we have no experts. Maybe earlz just wants to learn how to do it.

More power to the ambitious. But cryptography is not the field for learning-by-doing, or "public beta" style testing. If he really wants to find out what he's doing wrong - and here I don't mean programming mistakes or wrong compiler settings or somesuch - he should take his case to a cryptography-centered board.

In cryptography, the experience criteria is not "what have you made", but "what have you broken". Any new cipher or cryptosystem you come up with is worth no more than the sum of the worths of the cryptosystems you broke before you make it.

Well, not quite. Cryptanalysis and cryptology are two closely related, but still seperate field. You can become famous for a very good cypher without having broken a single non-trivial cypher in your life (although it's seldom for anyone to become proficient in one field without some hands-on experience in the other).

But the point I was trying to make is, cryptography stands and falls in the lab, not in the source. A broken implementation is easily fixed, a broken algorithm is simply worthless (unless you can get the bad boys to believe it's still safe to use ). It's simply not a subject of programming skill, craftmanship, or inspiration, but of theory, mathematics, and logic.

Of course, but nobody is going to cryptanalyse a system by a nobody (unless it gets widely deployed, e.g. LanMan hash), so you have to become a somebody. Breaking existing systems and publishing this serves the dual purpose of getting your name out there and teaching you about what other people have done wrong.