On 08/20/2015 03:11 PM, James Starkey wrote: > On Thursday, August 20, 2015, Alex Peshkoff <peshk...@mail.ru> wrote: > >> On 08/18/2015 12:22 AM, Jim Starkey wrote: >>> Unless it can be guaranteed that SRP verifiers in Firebird are immune >>> to compromised >> What do you mean by 'immune to compromised' here? The main goal of using >> SRP as a default authentication method in FB3 was to avoid sending plain >> passwords over the wire. SRP verifiers are stored by default in separate >> security database not accessible remotely at all. The next step of >> verifiers protection is keeping them in SYSDBA-only readable table. But >> may be I understand 'compromised' wrong here? > > By compromised I mean that a miscreant hacks into the server and steals the > security database. The tradition way to do that is to put a password > sniffer in a LAN and wait for somebody to do something stupid.
And this may be something not directly firebird related (I'm referencing a stolen key-cards database). Yes, certainly enhancing security in a case of stolen verifiers is also important. Using firebird-only tools it's impossible to steal hashes remotely even knowing SYSDBA's password, but that database is placed on a disk and there are really other ways to steal it. > You could argue that anyone who could steal the security database could > also steal the production database, which is true. The the potential for > real havoc depends on malicious interaction using forged/stolen credentials. Certainly. Ability to modify data in production database is often more interesting than just stealing it. > You can't protect data files from a bad guy with the root password, but you > can limit the damage he can do. Of couse he could also replace the > Firebird image with a hacked version, but ... but we probably can't do something with it... And what about the vault at the client side containing long randomly generated password for SRP - this is definitely a way to make things not as bad as they can when verifiers are compromised. I suppose to use this suggestion in post-3 release of firebird. The problem I see now is that it's very much client-dependent, i.e. how can server be sure that when password is changed client did send to it really high-quality random password? ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
