Looks like simpler Java frameworks are on the rise now ( http://www.pippo.ro/ , http://sparkjava.com/ , http://www.rapidoid.org/ )
Very happy to see this trend catch up with Java.
Blade: a Java Web Framework
11–20 of 61 posts
Re: Blade: a Java Web Framework
#12Earlier quoted context omitted.
You mean: as framework creator you should make your documentation reflect the latest security standards right? Just to make sure.
I think dodyg's point is more that someone using MD5 as a password hash is unlikely to have created a modern, secure, well-designed framework. If there's a problem as significant as poor password security then there's very likely to be other more subtle problems as well.
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to?
Brute forcing md5 is easier than some other hashing algo because of collisions?
(And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
Re: Blade: a Java Web Framework
#13Looks like simpler Java frameworks are on the rise now ( http://www.pippo.ro/ , http://sparkjava.com/ , http://www.rapidoid.org/ )
You can add this one to the list: http://www.takes.org/
Re: Blade: a Java Web Framework
#14No offence, but this is basically the poor man's Finagle. Except Finagle is Netty based, and this is Jetty based.
Anyway, this API is really as terse as one can get with Java. Great developer-UX job!
Re: Blade: a Java Web Framework
#15Earlier quoted context omitted.
I think dodyg's point is more that someone using MD5 as a password hash is unlikely to have created a modern, secure, well-designed framework. If there's a problem as significant as poor password security then there's very likely to be other more subtle problems as well.
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to? Brute forcing md5 is easier than some other hashing algo because of collisions? (And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
MD5 is pretty cheap to compute. According to this Stack Exchange post[0], a GPU can do billions of hashes per second, so a short/weak password would be quickly cracked.
[0] http://security.stackexchange.com/questions/38134/what-are-r...
Re: Blade: a Java Web Framework
#16Earlier quoted context omitted.
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to? Brute forcing md5 is easier than some other hashing algo because of collisions? (And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
MD5 is pretty cheap to compute. According to this Stack Exchange post[0], a GPU can do billions of hashes per second, so a short/weak password would be quickly cracked. [0] http://security.stackexchange.com/questions/38134/what-are-r...
If someone has local access then it's easy to crack any passwords (of any hashing algo). However if the cracker has local access and/or full access to DB then weak password hashing is one of the least problems..
Making password checking slower is very easy if the cracker doesn't have local access. Just sleep for XXX ms at every hash check and double it for every incorrect attempt (per IP).
Re: Blade: a Java Web Framework
#17Earlier quoted context omitted.
I think dodyg's point is more that someone using MD5 as a password hash is unlikely to have created a modern, secure, well-designed framework. If there's a problem as significant as poor password security then there's very likely to be other more subtle problems as well.
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to? Brute forcing md5 is easier than some other hashing algo because of collisions? (And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
MD5 is cheap enough to brute force now that we're talking "moderate annoyance" instead of "heat death of the universe" territory.
Re: Blade: a Java Web Framework
#18I'm a bit tired of these sinatra like web frameworks these days. Repetitive url patterns are not that elegant. Why not simply building the API around the fundamental REST concept, the resource? And what about proper content negotiation?
JAX-RS has a nice API without much boilerplate and it is more powerful than most "micro web frameworks".
Re: Blade: a Java Web Framework
#19Earlier quoted context omitted.
MD5 is pretty cheap to compute. According to this Stack Exchange post[0], a GPU can do billions of hashes per second, so a short/weak password would be quickly cracked. [0] http://security.stackexchange.com/questions/38134/what-are-r...
If someone has local access then it's easy to crack any passwords (of any hashing algo). However if the cracker has local access and/or full access to DB then weak password hashing is one of the least problems.. Making password checking slower is very easy if the cracker doesn't have local access. Just sleep for XXX ms at every hash check and double it for every incorrect attempt (per IP).
Password hashes are stolen in a variety of ways, when attackers find a way to dump arbitrary files or get results of arbitrary SQL strings, even one byte at a time. Yes, if that happens the site is toast, but 99% of its users have used that password somewhere (everywhere) else. That's not your fault, but using a better hashing algorithm is so trivial that it makes you an asshole to betray your users like that.
Re: Blade: a Java Web Framework
#20Earlier quoted context omitted.
I think dodyg's point is more that someone using MD5 as a password hash is unlikely to have created a modern, secure, well-designed framework. If there's a problem as significant as poor password security then there's very likely to be other more subtle problems as well.
As I'm not up to the current security research, what is problem with using md5 hash of name+password? Is the missing salt problem you are refering to? Brute forcing md5 is easier than some other hashing algo because of collisions? (And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
Speed is the problem. ocl-hashcat can test in the region of 6 billion MD5 hashes a second on a decent GPU. With a random salt and, say, an 8 character password it'd take a long time, but not so long it's impossible. On a site that includes rules like 'Must have an uppercase letter', 'Must include a number', and 'Must include a special character' you actually reduce the size of the space and consequently make the password easier to brute force. With those rules in place there's 159,655,911,367,680 possible passwords[1], so brute forcing at 6 billion hashes a second it'd take just over 7 hours. Maybe double that for the overhead of adding in the salt and managing the list of attempts, etc.
The point is it's achievable. If someone gets a dump of the database it can be turned back in to usable accounts. If you use something much slower they can't. There's no benefit to using MD5. On the other hand, using a better hashing algorithm protects user's passwords from brute force attacks. Why wouldn't you want that?
Quite a good article about cracking a well designed database of bcrypt'd passwords - http://arstechnica.com/security/2015/08/cracking-all-hacked-...