Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 26/02/2019 16:20, Mark Rotteveel wrote: UserManager = Legacy_UserManager I think had the ", Srp" in the earlier version and it's that which I was adding back first ... leaving it out THEN AuthServer = Legacy_Auth, Srp is not causing a problem! Specifying UserManager = Legacy_UserManager will allow you to manage (create/drop/alter) legacy authentication users only. Using UserManager = Legacy_UserManager, Srp will allow you to manage both, while legacy is the default. It should not affect authentication behavior as far as I'm aware, though. I can now confirm that on 3.0.4 I can add ', Srp' to enable SRP as a second option and things are running fine. On 3.0.2 as shipped with the current stable distribution of SUSE the only way to get legacy to work is to drop Srp from all three settings. I can't see any reason that SUSE could not be rolled forward to 3.0.4 on the stable release? And that is the correct path for this but I'll update my own cribsheet giving access to the 3.0.4 version via the server:database repo on SUSE. ( And I've found the missing video streaming was down to simply needing to reboot the linux based tuner ... it can be a problem at times when one changes something working out just which bit HAS broken ... thg is also up and working again after rolling back to an older build that matches the available hggit ... so now to add some new code! ) -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 25-2-2019 16:49, Lester Caine wrote: On 25/02/2019 15:12, Alex Peshkoff via Firebird-devel wrote: page 125 in relnotes 3.0.3 (and I believe not far from it in other versions): Bear in mind in my case I was provided with 3.0.2 via SUSE and even finding the release notes was an exercise. I'm fairly sure that this said specifically DO NOT do something if you are only going to use legacy connections ... yep ... The same red box appears on the 3.0.4 version! 3.0.4 copy I am looking at now only refers to adding the default SYSDBA user and in my case this did exist but the 'Legacy Authentication' section I THINK has a change? Yes, and I think that instruction is not entirely correct. It seems to be predicated on the assumption that the configuration applied by the Windows installer to the `firebird.conf` (or the manual instructions in Legacy Authentication) is also applied to the client, which is not the case (at least, not on Windows). So the client will try Srp first, which then results in an error because Srp was not initialised. UserManager = Legacy_UserManager I think had the ", Srp" in the earlier version and it's that which I was adding back first ... leaving it out THEN AuthServer = Legacy_Auth, Srp is not causing a problem! Specifying UserManager = Legacy_UserManager will allow you to manage (create/drop/alter) legacy authentication users only. Using UserManager = Legacy_UserManager, Srp will allow you to manage both, while legacy is the default. It should not affect authentication behavior as far as I'm aware, though. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 25-2-2019 15:05, Alex Peshkoff via Firebird-devel wrote: On 2/25/19 4:45 PM, Mark Rotteveel wrote: On 25-2-2019 13:51, Alex Peshkoff via Firebird-devel wrote: On 2/24/19 10:52 AM, Mark Rotteveel wrote: The security database inside the distribution is already initialized with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be done for SRP (or at least: isn't done for SRP). First half of an answer is very simple - in order to avoid network server running with SYSDBA/masterkey login in default configuration. Looking at this discussion I once again notice that this protection is rather efficient :) Then lets change this question to why the security database in the distribution isn't initialized for SRP (ie having the PLG$SRP table, maybe other things needed). Would it be possible to initialize it as part of the distribution **without** having a user present? That at least would avoid the "Look at the compatibility chapter" error. It will be very useful for a user which started to change configuration file not understanding it to read an instruction instead of continuing in random order. Once again - if one includes SRP in configuration security DB should contain at least one SRP user, if there are no users why include it at all? Because otherwise, if you try to login with Legacy_Auth, while the default order tries Srp first, you get an error. And instead of continuing the authentication process with the next plugin, the process ends. I don't think that is the right approach. Either the default security database should be created in such a way that SRP does not fail, **or** failures like this should just continue with the next available plugin. There can be all kinds of reasons for this, including wanting to be able to use both Srp and Legacy_Auth, but starting your server without having added a Srp user yet, and then not being able to login at all (not even with the Legacy_Auth SYSDBA), that is extremely confusing if you are not familiar. Yes, **I** know how to fix this, because I have been bitten enough by it during the testing of Firebird 3 that I automatically set things correctly when installing a clean version (because I need both Srp and Legacy_Auth for my testing). But this is ultimately something that affects the usability of Firebird when you start with it. The assumption in how it currently works (and, IMO, the instructions in the release notes), is based too much on the assumption that you use either Legacy_Auth or Srp, and not a combination. It also seems to be predicated on an assumption that the `AuthClient` setting in the `firebird.conf` of the server is also used for the client, which is definitely not the case on Windows, and probably also not on Linux. And given the default security database does contain a legacy auth with SYSDBA/masterke it is insecure anyway for people who'll enable Legacy_Auth. If anyone himself changed configuration to include legacy plugin he definitely gets insecure configuration. Certainly I talk about default configuration which was already mentioned explicitly. This discussion is in the context of having enabled Legacy_Auth in the installer (or otherwise), so of course my assumption includes Legacy_Auth. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 25/02/2019 15:12, Alex Peshkoff via Firebird-devel wrote: page 125 in relnotes 3.0.3 (and I believe not far from it in other versions): Bear in mind in my case I was provided with 3.0.2 via SUSE and even finding the release notes was an exercise. I'm fairly sure that this said specifically DO NOT do something if you are only going to use legacy connections ... yep ... The same red box appears on the 3.0.4 version! 3.0.4 copy I am looking at now only refers to adding the default SYSDBA user and in my case this did exist but the 'Legacy Authentication' section I THINK has a change? UserManager = Legacy_UserManager I think had the ", Srp" in the earlier version and it's that which I was adding back first ... leaving it out THEN AuthServer = Legacy_Auth, Srp is not causing a problem! Now back to trying to find out why streaming video is broken :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 2/25/19 5:51 PM, Lester Caine wrote: On 25/02/2019 14:05, Alex Peshkoff via Firebird-devel wrote: Then lets change this question to why the security database in the distribution isn't initialized for SRP (ie having the PLG$SRP table, maybe other things needed). Would it be possible to initialize it as part of the distribution **without** having a user present? That at least would avoid the "Look at the compatibility chapter" error. It will be very useful for a user which started to change configuration file not understanding it to read an instruction instead of continuing in random order. Once again - if one includes SRP in configuration security DB should contain at least one SRP user, if there are no users why include it at all? If I am reading this correctly then I was correct last month when I simply ended up stripping all but the Legacy options from the config file? Rather than following the 'compatibility chapter' which I don't think makes any mention about creating a srp user ... page 125 in relnotes 3.0.3 (and I believe not far from it in other versions): Initializing the Security Database By default, Firebird 3 is configured for the new authentication model which uses SRP to work with user pass- words and generate unique session identifiers for traffic encryption. The security database (security3.fdb) has no predefined users. This is intentional. However, when using the standard installers for Windows, Linux and MacOSX, the SYSDBA user is created during the final step of the installation, with a password that is either random or defined via a user input routine. In a situation where the SYSDBA initialization step either fails, or is missing from an OS-specific install process, such as a Windows .zip kit install or a dedicated POSIX platform port, it may be necessary to initialize the security database manually for use with the SRP plugins. You will need to create the user SYSDBA and set up the password for it using SQL CREATE USER command syntax in embedded mode as your first step to getting access to databases and utilities. and so on... Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 2/25/19 5:51 PM, Lester Caine wrote: On 25/02/2019 14:05, Alex Peshkoff via Firebird-devel wrote: Then lets change this question to why the security database in the distribution isn't initialized for SRP (ie having the PLG$SRP table, maybe other things needed). Would it be possible to initialize it as part of the distribution **without** having a user present? That at least would avoid the "Look at the compatibility chapter" error. It will be very useful for a user which started to change configuration file not understanding it to read an instruction instead of continuing in random order. Once again - if one includes SRP in configuration security DB should contain at least one SRP user, if there are no users why include it at all? If I am reading this correctly then I was correct last month when I simply ended up stripping all but the Legacy options from the config file? Rather than following the 'compatibility chapter' which I don't think makes any mention about creating a srp user ... it's about manually creating a legacy SYSDBA/xxx which in the case of the SUSE install already existed. It WAS only when I removed the srp ( and windows ) entries that I could get in. I've a stack of 6 servers out in the workshop each with their own copy of firebird but also using versions on other machines in the stack as backups. The 3050 port is not enabled outside the network and apart from using Flamerobin for manual tweaks, everything else is accessed via PHP, so DO I need to worry about SRP on this setup? Lester, as I've already said: if you are sure that nothing untrusted can reach your port 3050 - what a difference what authentication plugin is used? The only small one - legacy is slightly faster. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 25/02/2019 14:05, Alex Peshkoff via Firebird-devel wrote: Then lets change this question to why the security database in the distribution isn't initialized for SRP (ie having the PLG$SRP table, maybe other things needed). Would it be possible to initialize it as part of the distribution **without** having a user present? That at least would avoid the "Look at the compatibility chapter" error. It will be very useful for a user which started to change configuration file not understanding it to read an instruction instead of continuing in random order. Once again - if one includes SRP in configuration security DB should contain at least one SRP user, if there are no users why include it at all? If I am reading this correctly then I was correct last month when I simply ended up stripping all but the Legacy options from the config file? Rather than following the 'compatibility chapter' which I don't think makes any mention about creating a srp user ... it's about manually creating a legacy SYSDBA/xxx which in the case of the SUSE install already existed. It WAS only when I removed the srp ( and windows ) entries that I could get in. I've a stack of 6 servers out in the workshop each with their own copy of firebird but also using versions on other machines in the stack as backups. The 3050 port is not enabled outside the network and apart from using Flamerobin for manual tweaks, everything else is accessed via PHP, so DO I need to worry about SRP on this setup? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 2/25/19 4:45 PM, Mark Rotteveel wrote: On 25-2-2019 13:51, Alex Peshkoff via Firebird-devel wrote: On 2/24/19 10:52 AM, Mark Rotteveel wrote: The security database inside the distribution is already initialized with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be done for SRP (or at least: isn't done for SRP). First half of an answer is very simple - in order to avoid network server running with SYSDBA/masterkey login in default configuration. Looking at this discussion I once again notice that this protection is rather efficient :) Then lets change this question to why the security database in the distribution isn't initialized for SRP (ie having the PLG$SRP table, maybe other things needed). Would it be possible to initialize it as part of the distribution **without** having a user present? That at least would avoid the "Look at the compatibility chapter" error. It will be very useful for a user which started to change configuration file not understanding it to read an instruction instead of continuing in random order. Once again - if one includes SRP in configuration security DB should contain at least one SRP user, if there are no users why include it at all? And given the default security database does contain a legacy auth with SYSDBA/masterke it is insecure anyway for people who'll enable Legacy_Auth. If anyone himself changed configuration to include legacy plugin he definitely gets insecure configuration. Certainly I talk about default configuration which was already mentioned explicitly. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
25.02.2019 15:51, Alex Peshkoff via Firebird-devel wrote: The security database inside the distribution is already initialized with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be done for SRP (or at least: isn't done for SRP). First half of an answer is very simple - in order to avoid network server running with SYSDBA/masterkey login in default configuration. There's also a different approach to this, used by some other databases. In our case it would look like this: RemoteBindAddress = 127.0.0.1 Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 2/24/19 10:52 AM, Mark Rotteveel wrote: On 23-2-2019 20:56, Lester Caine wrote: On 23/02/2019 19:21, Paul Reeves wrote: It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. IIRC, rpm install 2.5 used to initialize security database using random password for sysdba. Was it changed in 3.0? I only know the suse packages. The security db was left unitialised. The fresh install using the packages currently supported by SUSE Leap 15.0 defaults to 'masterke', Shame on them... and as always the first thing I do is change that via flamerobin. The security database inside the distribution is already initialized with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be done for SRP (or at least: isn't done for SRP). First half of an answer is very simple - in order to avoid network server running with SYSDBA/masterkey login in default configuration. Looking at this discussion I once again notice that this protection is rather efficient :) And that has been done in this case. My problem with the 'Compatibility chapter' on the previous install was that I was unable to access the database until I REMOVED Srp from the config file. I have no worries about the legacy system being 'less secure' simply because the only application accessing it is PHP on a local network link and I don't need any more than that so why should I have to do any more than getting a single user working? The problem is essentially http://tracker.firebirdsql.org/browse/CORE-5485 which Alex doesn't consider to be a bug. If you create a single Srp user, this will go away. And you have to create a user (or users) anyway for your application(s), so why not just use Srp for that? To be precise - if some application does not use firebird's access rights control (it's using same login for all attaches) and you are quite sure in reliability of infrastructure protecting server running firebird from undesired access I see no reason to use srp. Legacy plugin is faster - needs less CPU to establish connection. But in this case what's a need to add more plugins to configuration file? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 2/23/19 7:54 PM, Dimitry Sibiryakov wrote: 23.02.2019 17:51, Paul Reeves wrote: It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. IIRC, rpm install 2.5 used to initialize security database using random password for sysdba. Was it changed in 3.0? Supporting of RPM in _our_ (i.e. SF) binaries became unreal. That's first of all because no matter of the fact that all them have .rpm extensions and even same internal format _content_ of RPMs for different distro should be a bit different, and this difference does not get smaller from year to year. We used to fix (but "hack" is more precise word here) that using post-install script which in turn caused fatal problems when trying to upgrade firebird using our .rpm. That's why support of rpm's was dropped in FB3. Certainly various distro provide binaries in rpm form but we (project) do not publish rpm's any more. I.e. any question regarding ability to initialize security database using random password should better be asked not here. On my mind that should be possible. Moreover, it's done in a case of using '-silent' switch in install.sh from .tar.gz binary package and when doing 'make silent_install' when building from sources. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23-2-2019 20:56, Lester Caine wrote: On 23/02/2019 19:21, Paul Reeves wrote: It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. IIRC, rpm install 2.5 used to initialize security database using random password for sysdba. Was it changed in 3.0? I only know the suse packages. The security db was left unitialised. The fresh install using the packages currently supported by SUSE Leap 15.0 defaults to 'masterke', and as always the first thing I do is change that via flamerobin. The security database inside the distribution is already initialized with a Legacy_Auth SYSDBA only. I'm not sure why the same can't be done for SRP (or at least: isn't done for SRP). And that has been done in this case. My problem with the 'Compatibility chapter' on the previous install was that I was unable to access the database until I REMOVED Srp from the config file. I have no worries about the legacy system being 'less secure' simply because the only application accessing it is PHP on a local network link and I don't need any more than that so why should I have to do any more than getting a single user working? The problem is essentially http://tracker.firebirdsql.org/browse/CORE-5485 which Alex doesn't consider to be a bug. If you create a single Srp user, this will go away. And you have to create a user (or users) anyway for your application(s), so why not just use Srp for that? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23/02/2019 19:21, Paul Reeves wrote: It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. IIRC, rpm install 2.5 used to initialize security database using random password for sysdba. Was it changed in 3.0? I only know the suse packages. The security db was left unitialised. The fresh install using the packages currently supported by SUSE Leap 15.0 defaults to 'masterke', and as always the first thing I do is change that via flamerobin. And that has been done in this case. My problem with the 'Compatibility chapter' on the previous install was that I was unable to access the database until I REMOVED Srp from the config file. I have no worries about the legacy system being 'less secure' simply because the only application accessing it is PHP on a local network link and I don't need any more than that so why should I have to do any more than getting a single user working? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On Sat, 23 Feb 2019 17:54:40 +0100 Dimitry Sibiryakov wrote: > 23.02.2019 17:51, Paul Reeves wrote: > > It is linked to the fact that rpm installs don't allow > > interaction at install time, so the security database is not > > initialised. > >IIRC, rpm install 2.5 used to initialize security database using > random password for sysdba. Was it changed in 3.0? > I only know the suse packages. The security db was left unitialised. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
23.02.2019 17:51, Paul Reeves wrote: It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. IIRC, rpm install 2.5 used to initialize security database using random password for sysdba. Was it changed in 3.0? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On Sat, 23 Feb 2019 16:28:46 +0100 Mark Rotteveel wrote: > > I think that a lot of grief could have been avoided if SRP > initialization would have been done as part of the default > initialization of the security3.fdb in the distribution instead of > leaving that to the users. > As far as linux and Firebird 3 is concerned that is definitely a problem. It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23-2-2019 13:02, Lester Caine wrote: On 23/02/2019 11:23, Mark Rotteveel wrote: Yes it is working, even with Firebird 3; except maybe Firebird 3.0.0 and 3.0.1 as I recall there were issues with some of the early versions, but I can't recall if that was pre-release or not. I beg to differ! I've just been working through this in the last few days. Clean machine ... fresh install of SUSE 15.0/Gnome ... all software installed onto new main disk ( data disks separate ). Firebird 3.0.2 along with Flamerobin 0.9.3.1, nginx 1.14.0 and PHP 7.2.5 Why 3.0.2? Firebird 3.0.4 has been out for almost 5 months now (and 3.0.3 a year). From previous experience I had stripped the firebird.conf back to AuthServer = Legacy_Auth AuthClient = Legacy_Auth UserManager = Legacy_UserManager WireCrypt = Disabled I can add ', Srp' to UserManager and AuthClient but if I add it to AuthServer then both Flamerobin and PHP fail to connect. FlameRobin gives --- Engine Code : 335544472 Engine Message : Your user name and password are not defined. Ask your database administrator to set up a Firebird login. Install incomplete, please read the Compatibility chapter in the release notes for this version --- So currently I have AuthServer = Legacy_Auth AuthClient = Legacy_Auth, Srp UserManager = Legacy_UserManager, Srp WireCrypt = Disabled And I am connecting and working ... AVOIDING following the Compatibility chapter ... so where am I going wrong? Why are you spending so much energy avoiding that chapter? In any case, if Srp is checked before Legacy_Auth the security database must be properly initialized for Srp. And Srp will be checked first if AuthServer **contains** Srp (in any order) when the client starts with Srp (the client is leading with regard to order of authentication). If you are using a Firebird 3 fbclient that doesn't have a firebird.conf in the same directory as the fbclient.dll / libfbclient.so, it will use the default AuthClient setting, which has Srp first, which means an authentication attempt with Srp will be done first. Which is likely what happens in your case. The AuthClient setting in the server firebird.conf is only applied when the server acts as a client (execute statement on external datasource), it doesn't apply to client libraries in a different location. You need to initialize the security database for SRP to get rid of that error. This can be done by creating a user (any user) with SRP. Creating a user (and - if not needed - dropping that user) should be enough (see also a similar exchange we had in January, eg my post in firebird-support at 17 Jan 2019 21:28:16 +0100). create user someuser password 'xyz' using plugin Srp; commit; -- optionally drop user drop user someuser using plugin Srp; commit; I think that a lot of grief could have been avoided if SRP initialization would have been done as part of the default initialization of the security3.fdb in the distribution instead of leaving that to the users. I think in your setup you shouldn't even need to use Legacy_Auth assuming all clients can be deployed with a Firebird 3 fbclient. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23/02/2019 11:23, Mark Rotteveel wrote: Yes it is working, even with Firebird 3; except maybe Firebird 3.0.0 and 3.0.1 as I recall there were issues with some of the early versions, but I can't recall if that was pre-release or not. I beg to differ! I've just been working through this in the last few days. Clean machine ... fresh install of SUSE 15.0/Gnome ... all software installed onto new main disk ( data disks separate ). Firebird 3.0.2 along with Flamerobin 0.9.3.1, nginx 1.14.0 and PHP 7.2.5 From previous experience I had stripped the firebird.conf back to AuthServer = Legacy_Auth AuthClient = Legacy_Auth UserManager = Legacy_UserManager WireCrypt = Disabled I can add ', Srp' to UserManager and AuthClient but if I add it to AuthServer then both Flamerobin and PHP fail to connect. FlameRobin gives --- Engine Code: 335544472 Engine Message : Your user name and password are not defined. Ask your database administrator to set up a Firebird login. Install incomplete, please read the Compatibility chapter in the release notes for this version --- So currently I have AuthServer = Legacy_Auth AuthClient = Legacy_Auth, Srp UserManager = Legacy_UserManager, Srp WireCrypt = Disabled And I am connecting and working ... AVOIDING following the Compatibility chapter ... so where am I going wrong? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23-2-2019 10:31, Lester Caine wrote: On 23/02/2019 08:14, Mark Rotteveel (JIRA) wrote: Personally, I'd also prefer if UserManager order would be set to Srp, Legacy_UserManager, but to support legacy tools that is not really an option. *IS* including the other options in any of the entries tested and working when one is using FB2.x and FB3 systems in parallel? Certainly I've had to strip everything but Legacy_Auth and Legacy_UserManager in order to get my PHP setups to run with FB3! So is FB4 any different? Yes it is working, even with Firebird 3; except maybe Firebird 3.0.0 and 3.0.1 as I recall there were issues with some of the early versions, but I can't recall if that was pre-release or not. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On 23/02/2019 08:14, Mark Rotteveel (JIRA) wrote: Personally, I'd also prefer if UserManager order would be set to Srp, Legacy_UserManager, but to support legacy tools that is not really an option. *IS* including the other options in any of the entries tested and working when one is using FB2.x and FB3 systems in parallel? Certainly I've had to strip everything but Legacy_Auth and Legacy_UserManager in order to get my PHP setups to run with FB3! So is FB4 any different? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
Enabling legacy authentication in Windows installer leads to less secur config than possible Key: CORE-6011 URL: http://tracker.firebirdsql.org/browse/CORE-6011 Project: Firebird Core Issue Type: Bug Components: Build Issues / Porting, Installation, Security Affects Versions: 4.0 Beta 1 Reporter: Mark Rotteveel When you enable legacy authentication in the Windows installer, it will configure firebird.conf with AuthServer = Legacy_Auth, Srp, Win_Sspi AuthClient = Legacy_Auth, Srp, Win_Sspi This is insecure for two reasons: 1. It is missing the new Srp256 plugin which is the default 2. The order for authentication plugins should be from most secure to least secure to avoid leaking information about credentials of Srp users (eg if Srp256 or Srp succeeds, there is no need to send the password using the less secure UnixCrypt hash in Legacy_Auth). In other words, enabling legacy authentication should produce AuthServer = Srp256, Win_Sspi, Legacy_Auth (or maybe AuthServer = Srp256, Srp, Win_Sspi, Legacy_Auth) The default for AuthClient (AuthClient = Srp256, Srp, Win_Sspi, Legacy_Auth) is already sufficient and secure enough, so there is no need to write an explicit config. Personally, I'd also prefer if UserManager order would be set to Srp, Legacy_UserManager, but to support legacy tools that is not really an option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
