Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
It remains a functional relational database. It has a BSD-style license with a very stable, nearly bug-free (see Coverity) core. It has modular design (you can write procedures in Java, C, C++, T/SQL, R, Python and others. You can get commercial support from a company (EnterpriseDB) that doesn't have a vested interest in moving you to a very expensive alternative.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
mysql> create table foo(bar varchar(10)); mysql> insert into foo (bar) values ('abc'); mysql> select * from foo where bar = 'abc'; +------+ | bar | +------+ | abc | +------+ 1 row in set (0.00 sec)
mysql> select * from foo where bar = 'aBC'; +------+ | bar | +------+ | abc | +------+
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
If you're storing passwords in the database in plaintext, you're doing it wrong. Personally, I don't think they should be stored in any recoverable way, but there's a legitimate argument to the opposite. Either way you're using a transformation function on the password field that does take case into account.
Either way you're using a transformation function on the password field that does take case into account.
Except it won't:
> select * from users where username='foo' and password=encrypt('foo', 'salt');
...will return a row if the encrypted version of 'foo' matches any case-insensitive permutation of the encrypted version of the real password. Now, you can rewrite that to match case as other people here have pointed out, but it's insane that the default behavior is to allow sloppy matches. It never would have occurred to me that "=" doesn't really mean "equals" before reading it here.
Right, but then you're talking about the ridiculously large space or encrypted passwords instead of plaintext passwords which are a much smaller space. I agree with you that it's weird and probably wrong behavior, but it's not a security risk to an application that would have been considered secure otherwise.
The only person who always got his work done by Friday was Robinson Crusoe.
What about MySQL? (Score:5, Interesting)
Well well well. I can see this working well for Oracle - they use Java a great deal... and it should be good news for Sun's open source projects like Netbeans - which would, I think, be maintained under Oracle.
I guess it's a little sad to see Sun unable to continue by themselves, but the writing was on the wall and I think Oracle will keep all the Sun products working, but of course the big question is what does this mean for MySQL?
Postgres is looking better than ever (Score:5, Informative)
Re: (Score:1)
Re: (Score:1, Insightful)
Their string comparisons are case sensitive.
OMFG, massive fail for MySQL. I thought you were joking, but you aren't!
Imagine an OS where strcmp() was case insensitive, and where it was used to compare hashed passwords when authenticating users. Realize that base64 is no
Re:Postgres is looking better than ever (Score:2)
Re: (Score:2)
Either way you're using a transformation function on the password field that does take case into account.
Except it won't:
...will return a row if the encrypted version of 'foo' matches any case-insensitive permutation of the encrypted version of the real password. Now, you can rewrite that to match case as other people here have pointed out, but it's insane that the default behavior is to allow sloppy matches. It never would have occurred to me that "=" doesn't really mean "equals" before reading it here.
Re: (Score:2)