Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On Wed, 19 Aug 2015 14:55:33 -0400, Jim Starkey j...@jimstarkey.net
wrote:
You're excessing fussy. No one has ever found a SHA1 collision, let
alone a bogus hit. It is perfectly secure. It has known weaknesses,
but even with these known weaknesses, it is impossible to crack.
RC4 is perfectly secure. It is vulnerable to correlated keys as used in
WEP. But SRP uses a session key that is a function of { server random
number, client random number, salt, password }. Keys are NEVER reused
and are securely computed separately on the two sides.
You need to understand something about cryptography before getting your
knickers in a twist.
I may not be an expert in cryptography, but I know enough for my day to
day work.
There are more important things to worry about that the choice of
algorithm, for example, the manifest weaknesses of human chosen keys.
There is no point to pandering to the ignorant. If they read only
Google News headlines, they'll get upset no matter what you do.
In my initial post I intentionally did not address the technological
details, as my intention was specifically to address the image part. The
industry consensus seems to be that moving away from RC4 and SHA1 is the
right course of action. That Firebird now (or likely 6 months from now)
release a new feature that builds on those dated algorithms is in my
opinion a PR problem, especially if you consider that it will stay for
years to come.
The best alternative to RC4 is AES-128. It is more (but not
measurably) secure but also a couple of hundred times as expensive to
compute. If you don't believe me, run your own numbers.
AES might be more expensive, but not that expensive, especially not when
you have hardware support for AES.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On Thursday, August 20, 2015, Michal Kubecek m...@mk-sys.cz wrote: On Wed, Aug 19, 2015 at 02:55:33PM -0400, Jim Starkey wrote: The best alternative to RC4 is AES-128. It is more (but not measurably) secure but also a couple of hundred times as expensive to compute. If you don't believe me, run your own numbers. I did... So it looks like couple of hundred means 6-8 when calculating AES in software and 1.25-1.35 when using in-CPU implementation (in this case, AMD FX-8150 from 2012). Anyway, I agree with most of the rest. Interesting. The tests I ran were in situ in early NuoDB, which encrypts all message traffic, including quite significant replication traffic. The RC4 was one I coded myself. The AES implimentation was from the open source Tom's Crypt Library. The overhead compared with unencrypted traffic was about 86% for AES-128 and about 5% for RC4. Perhaps much of the difference was in the qualities of the implementation. RC4 operates on a 256 byte state table, swapping two entries per operation XORing one with the next byte of the clear text. AES-128 operates on a 4 x 4 matrix of bytes, performing 10 rounds of four matrix operations per round. That said, much of the efficiency of AES is dependent on the key schedule algorithm computed at initialization time. I have no argument against AES, used properly, or RC4, again used properly. AES/ECB, aka simple AES, in some applications is more vulnerable than RC4 as used in WEP. But AES-128 and RC4 with pseudo random keys that are never reused are each unbreakable. If the press had latched onto the ineffectiveness of AES/ECB for encrypting an image, AES would be in the same dog house as RC4. AES/CBC XORs each input block with the encrypted output of the previous block, solving the problem. If you were starting over in a world when most servers had the AES instruction set, it would be a no brainer to use AES/CBC. But that isn't an argument switching with an installed base, though it does recommend an architecture where the choice of algorithm is a connection parameter. Anyway, you've convinced me to think about an overhaul of the encryption architecture of AmorphousDB. Thanks for pointing out my shameless exaggeration. -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On Thursday, August 20, 2015, Tommi Prami tommi.pr...@gmail.com wrote: Just my 0.02€ http://ianix.com/pub/chacha-deployment.html ChaCha20 is in TSL and OpenSSH etc. and mainly because it is secure and it is fast. I wasn't aware of that. Very, very cool. -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
You're excessing fussy. No one has ever found a SHA1 collision, let
alone a bogus hit. It is perfectly secure. It has known weaknesses,
but even with these known weaknesses, it is impossible to crack.
RC4 is perfectly secure. It is vulnerable to correlated keys as used in
WEP. But SRP uses a session key that is a function of { server random
number, client random number, salt, password }. Keys are NEVER reused
and are securely computed separately on the two sides.
You need to understand something about cryptography before getting your
knickers in a twist.
There are more important things to worry about that the choice of
algorithm, for example, the manifest weaknesses of human chosen keys.
There is no point to pandering to the ignorant. If they read only
Google News headlines, they'll get upset no matter what you do.
The best alternative to RC4 is AES-128. It is more (but not
measurably) secure but also a couple of hundred times as expensive to
compute. If you don't believe me, run your own numbers.
With AES-128, it is more likely that users will opt to forgo security
for reasons of performance.
Mark, you've been ranting about this for a long time. Please take some
time to master the concept of exponentiation. 2^80 is a lot smaller
than 2^160 but still so large that it can't be written out in digits.
Worry about the serious vulnerabilities, not insignificant weaknesses
found by academics and publicized by fools.
On 7/26/2015 4:03 AM, Mark Rotteveel wrote:
I have brought this up before, and it might be a bit annoying that I do
so again, but I remain concerned by the fact that we are about to ship a
product (Firebird 3) that uses hashing and encryption algorithms (SHA-1
and RC4) that most in the industry consider outdated and (relatively)
insecure.
Organizations are taking actions to deprecate and disable both (eg
Oracle disabled RC4 in TLS in Java 8 Update 51, the IETF now prohibits
the use of RC4 in TLS, https://tools.ietf.org/html/rfc7465).
They might still be strong enough for now, but I am also concerned about
the public image impact of releasing a product with a new security
feature that uses algorithms considered insecure by todays standards.
Mark
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On Monday, July 27, 2015, Alex Peshkoff peshk...@mail.ru wrote: On 07/26/2015 10:00 PM, Ivan Arabadzhiev wrote: Personally, I've recently started using (mostly for kicks) things like https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 I suppose the option to tune them in the future (or even introduce a configurable parameter) is also a plus. You may write authentication plugin using that things and use it in FB3, no changes in the rest of firebird are required for it. For people who do not need a lot of connections per second this may be useful. An interesting aspect of this approach is that is an architectural, pre-established denial of service facility. All that is necessary to render such a system unavailable is to hit it with a relatively low number of unsuccessful connection requests. If each takes one hundred milliseconds to compute the hash and reject the request, it would take only 10 * the number of cores capable of authentication to consume 100% of available cpu time. Virtually all authentication schemes have a substantial computation cost, but designing intentionally designing a scheme exposed to the world to maximize CPU consumption leads the system open to DOS by an attacker -- or an errant program. The ideal authentican scheme has zero cost and astronomic combinatorics so a brute force attack takes more time than the universe has to live until the Big Crunch. This dictates very large quasi-random passwords, but this is what password managers are all about. Scrypt and Bcrypt are, without doubt, fascinating thesis material, but their use in actual computing systems is stupid beyond belief. If you are concerned with deep robustness, bundle a client side password manager and require 32 character passwords. A simple password that an attacker never sees opens the vault. Firebird could be the first RDBMS on the block to have such a client. -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
27.07.2015 17:07, Jim Starkey wrote: Question: Does Firebird detect, report, and shutdown repetitive attacks on passwords? Yes, it does (in single-process architectures). Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
Sorry, you got taught wrong. Security is about the whole system, not one piece. Hash based security is vulnerable during password exchange, which a slow hash doesn't fix. Internet connections typically pass through a dozen routers, any of which could be configured to mount a man in the middle attack. The most important thing to get right is the security handshake. If that's weak, nothing else matters. On Monday, July 27, 2015, Jiří Činčura j...@cincura.net wrote: Really? Could you explain why an authentication scheme whose primary claim to fame is its high computational cost is a good choice for a database system that needs to do hundreds of authentications per minute or second? I've been taught that the hashing function for passwords should be slow. Hence it makes brute force attacks harder, because the attacker needs to wait for each attempt. -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On 07/26/2015 10:36 PM, Jim Starkey wrote: The bottom line is this: If you are going to change the password hash, you are going to invalidate all existing passwords. But rather than start over with an already flawed architecture, punt on storing passwords at all and go exclusively with SRP. When I've said that SHA1 hashes are stored in security database, I've meant exactly SRP verifiers. SHA1 is used for calculation of SRP verifier, and this is the only result of SHA1 stored in the database. BTW, except invalidation of all existing passwords this step also invalidates all old clients, including Java and C# clients, not using fbclient library. And it's hard to say what is worse. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
Internet connections typically pass through a dozen routers, any of which could be configured to mount a man in the middle attack. The most important thing to get right is the security handshake. If that's weak, nothing else matters. I agree. I, and I believe the original proposal, was mostly about offline cracking. But in that case stealing the actual database might be as good as passwords. :) -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
Not saying I want/need that for the moment, but you did ask for suggestions. And yes, the exact purpose of slow hashing is to make bruteforce attacks harder both with legit client attempts to authenticate, and when/if the user database is compromised. The latter might be a more valid reason to switch the algo used for storing password hashes. However, I also tend to think that anyone capable of an attack on SHA1 with proper(meaning something harder than masterkey/password/s.o.) passwords will probably find other means of attack and not bother bruteforcing so the benefit is questionable. As for throughoutput, I suppose there are people doing hundreds of connection per minute, but my guess would be systems with such load would use connection pooling (if nothing else, to speed up the process) and won`t be starting that many completely new connections. 2015-07-27 15:40 GMT+03:00 Alex Peshkoff peshk...@mail.ru: On 07/26/2015 10:00 PM, Ivan Arabadzhiev wrote: Personally, I've recently started using (mostly for kicks) things like https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 I suppose the option to tune them in the future (or even introduce a configurable parameter) is also a plus. You may write authentication plugin using that things and use it in FB3, no changes in the rest of firebird are required for it. For people who do not need a lot of connections per second this may be useful. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On 7/27/2015 8:35 AM, Alex Peshkoff wrote: On 07/26/2015 10:36 PM, Jim Starkey wrote: The bottom line is this: If you are going to change the password hash, you are going to invalidate all existing passwords. But rather than start over with an already flawed architecture, punt on storing passwords at all and go exclusively with SRP. When I've said that SHA1 hashes are stored in security database, I've meant exactly SRP verifiers. SHA1 is used for calculation of SRP verifier, and this is the only result of SHA1 stored in the database. That is as it should be. But as I said before, SHA-1 in SRP is used only to turn a known Bignum (which has many poor characteristics for an encryption key) into a 20 byte vector usable as a robust encryption key. BTW, except invalidation of all existing passwords this step also invalidates all old clients, including Java and C# clients, not using fbclient library. And it's hard to say what is worse. And for nothing to be gained... By the way, for those souls deeply concerned about accidental SHA-1 password collisions, the probability is 1 in 2^159 as the weaknesses of SHA-1 don't affect this problem. And despite the academic weakness of SHA-1, according to Wikipedia, nobody to date has found a SHA-1 collision, accidentally or intentionally. Question: Does Firebird detect, report, and shutdown repetitive attacks on passwords? -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On Sunday, July 26, 2015, Jiří Činčura j...@cincura.net wrote: Personally, I've recently started using (mostly for kicks) things like https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 I suppose the option to tune them in the future (or even introduce a configurable parameter) is also a plus. Agree. Really? Could you explain why an authentication scheme whose primary claim to fame is its high computational cost is a good choice for a database system that needs to do hundreds of authentications per minute or second? -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Jim Starkey -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
On 7/26/2015 2:38 PM, Alex Peshkoff wrote: On 07/26/2015 01:39 PM, James Starkey wrote: If you were starting over from scratch, you wouldn't want to use SHA-1 to avoid wasting time with discussions like this. See also RC4. But the problem with SHA-1 doesn't justify the inconvenience of changing it. I do not see serious inconveniences with it. BTW, what hash can you suggest instead? What is the application? It matters. The weakness of SHA-1 has to do with find collisions, which are any two strings with the same hash (to date, none have ever been found). But collisions have nothing to do with passwords, where a stored version is held constant. For passwords, SHA-1 is perfectly secure. That said, any scheme based on stored passwords, hashed or not, is susceptible to a man in the middle attack. It doesn't make any difference whether the man in the middle steals the password or the hash of the password -- either will do the trick. Such a system is so hopelessly insecure that the security of the hash doesn't matter. So rather than trying to improve the hash algorithm, if you're going to change anything, get rid of storing password hashes altogether in favor of only storing SRP verifiers. A compromised SRP verifier with a proper salt can be broken only by brute force and dictionary attacks, and even if broken, doesn't compromise past sessions. A better hash function is like a carbon fiber buggy whip. The problem isn't the buggy whip, the problem is the horse. There is a SHA-2 that is better than SHA-1. There is a SHA-3 under going development. SHA-2 is no more secure than SHA-1 was thought to be for its first 10 years. The bottom line is this: If you are going to change the password hash, you are going to invalidate all existing passwords. But rather than start over with an already flawed architecture, punt on storing passwords at all and go exclusively with SRP. Now, all that said, if the only use of SHA-1 is to flatten the master key in SRP into a session key, then there is no dependency on SHA-1 as a cryptographic hash, only as randomizing hash, and the weakness is irrelevant. But if it's used to store passwords, that's a security problem so huge that any SHA-1 weakness doesn't even come into it. Context is everything. Yes, SHA-1 is used to store password hashes. For SRP an exponent of SHA1(login, salt, password) modulus the prime is stored. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Insecure hashing and encryption in Firebird 3
Personally, I've recently started using (mostly for kicks) things like https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/PBKDF2 I suppose the option to tune them in the future (or even introduce a configurable parameter) is also a plus. Agree. -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
