Re: [HACKERS] Authentication mechanisms categorization
On Thu, Jul 20, 2017 at 01:00:50AM +0300, Álvaro Hernández Tortosa wrote: > I'm mostly convinced by the power of all the parameters that already > exist, given that you added both saslname and saslchannelbinding to the > already existing sslmode. That's great, and allows for very fine choosing of > the auth method. So it would be great if (non-libpq) driver implementations > would expose the same parameter names to the users. I will study this for > JDBC. Coming in late here, but the way TLS prevents authentication downgrade attacks is for the sender to send a list of supported authentication methods, and a hash of the supported authentication methods with a random number and a secret shared with the other end, and send that. If the list doesn't match the hash, it means the list is invalid. The secret prevents attackers from faking connections. I think the problem is that we don't have a consistent secret shared between the client and the server. We have md5 and SCRAM, but that doesn't help because the secret it tied to the authentication methods. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Authentication mechanisms categorization
On 14/07/17 13:29, Michael Paquier wrote: On Fri, Jul 14, 2017 at 12:16 PM, Álvaro Hernández Tortosa wrote: If the parameter authmethod would rather be "authmethods", i.e., a list, I think it would be significantly more flexible. Yes, but the handling of a list becomes messier if there are some other connection parameters that are dependent on the authentication method. Say if a list made of scram-sha-256 and scram-sha-3 as methods is sent, and a parameter named saslchannel lists scram-sha-256-plus is used, this becomes unusable with scram-sha-3. Using individual names for a parameter makes interactions with other parameters easier to handle and less bug-prone. That's also by experience more flexible for the application. I agree with a list of methods and all the values already existing for sslmode, this might be more than enough, specially if the channel binding SCRAM mechanisms would get a different authmethod than their non-channel binding partners (like scram-sha-256-plus). This makes the list argument for the authmethods, in my opinion, stronger. For the channel binding patch, I have actually implemented saslname to enforce the name of the SASL mechanism name to use (SCRAM-SHA-256 or its -PLUS) as well as saslchannelbinding to enforce the channel binding type. That's very handy, and at the end I saw that having a list does not add much value in a feature that should be as simple as possible as the client will use one match at the end for authentication, and let the client know if it failed or succeeded (yes I hate sslmode=prefer which does up to two attempts at once). But that's as far as my opinion stands. It is not possible to know the future, but we cannot discard as well the fact that a future authentication method, say hoge could as well support scram-sha-256, in which case cases like that using a list "authmethods=hoge,sasl authmechanisms=scram-sha-256" would mean that scram-sha-256 needs to be enforced for both things, but the dependency handling makes things unnecessary complicated in libpq. My argument here is crazy though. Hi Michael. I'm mostly convinced by the power of all the parameters that already exist, given that you added both saslname and saslchannelbinding to the already existing sslmode. That's great, and allows for very fine choosing of the auth method. So it would be great if (non-libpq) driver implementations would expose the same parameter names to the users. I will study this for JDBC. My only fear is that this could become very complicated for the user, and could end up looking like the authentication algorithm lists for SSL, which are very hard to digest for the non expert. To handle list of auth methods spread through three parameters, seem to me going a bit in this direction. A categorization like the one proposed, while maybe difficult to do initially, and maybe to maintain too, is just precisely to take this burden out from the user, and expose a simpler setting for them. Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Authentication mechanisms categorization
On Fri, Jul 14, 2017 at 12:16 PM, Álvaro Hernández Tortosa wrote: > If the parameter authmethod would rather be "authmethods", i.e., a list, > I think it would be significantly more flexible. Yes, but the handling of a list becomes messier if there are some other connection parameters that are dependent on the authentication method. Say if a list made of scram-sha-256 and scram-sha-3 as methods is sent, and a parameter named saslchannel lists scram-sha-256-plus is used, this becomes unusable with scram-sha-3. Using individual names for a parameter makes interactions with other parameters easier to handle and less bug-prone. That's also by experience more flexible for the application. > I agree with a list of methods and all the values already existing for > sslmode, this might be more than enough, specially if the channel binding > SCRAM mechanisms would get a different authmethod than their non-channel > binding partners (like scram-sha-256-plus). This makes the list argument for > the authmethods, in my opinion, stronger. For the channel binding patch, I have actually implemented saslname to enforce the name of the SASL mechanism name to use (SCRAM-SHA-256 or its -PLUS) as well as saslchannelbinding to enforce the channel binding type. That's very handy, and at the end I saw that having a list does not add much value in a feature that should be as simple as possible as the client will use one match at the end for authentication, and let the client know if it failed or succeeded (yes I hate sslmode=prefer which does up to two attempts at once). But that's as far as my opinion stands. It is not possible to know the future, but we cannot discard as well the fact that a future authentication method, say hoge could as well support scram-sha-256, in which case cases like that using a list "authmethods=hoge,sasl authmechanisms=scram-sha-256" would mean that scram-sha-256 needs to be enforced for both things, but the dependency handling makes things unnecessary complicated in libpq. My argument here is crazy though. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Authentication mechanisms categorization
On 14/07/17 11:09, Michael Paquier wrote: On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa wrote: There has been some prior discussion, that we recently continued at pgday.ru, about what to do if a client wants to use a "strong" authentication mechanism but a rogue server forces the client to use a weaker authentication mechanism. This is the case if the client expects SCRAM to be used but a rogue server just replies with AuthenticationCleartextPassword, for example. Client drivers will authenticate using this latter mechanism, transparently (at least pgjdbc implementation does this, and I believe libpq also). This somehow defeats the purpose of some mechanisms like SCRAM. Yeah :( It was discussed to add a parameter to the driver like "SCRAM-only", but I think this may not be ideal. "SCRAM-only" means that code needs to be written to prevent every other authentication mechanism, explicitly, which is far from ideal. Much worse, it defeats using other auth mechanisms that might be OK for the user. Also, this doesn't consider whether SCRAM is good without channel binding. I think it would be better to make a categorization of authentication mechanisms and then have an agreement among libpq and drivers to set a minimum level of security based on the user's request. Some initial ideas are: - Three security levels: Basic, Medium, Advanced. - Prevents MITM / does not. - Given this X possible attacks, a matrix of which mechanisms avoid which attacks (something similar to the table comparing the possible effects of the different isolation levels). This is not trivial: for example, SCRAM may be OK without channel binding in the presence of SSL, but without SSL channel binding is a must to prevent MITM. Similarly, are other auth mechanisms like Kerberos (I'm not an expert here) as "safe" as SCRAM with our without channel binding? The use of channel binding is linked to SSL, which gets already controlled by sslmode. H yes. As of today. Maybe tomorrow there's a channel binding mechanism that does not make use of SSL. But this is also unlikely. Users won't get trapped in this area by using "require" instead of the default of "prefer". I would love to see the default value changed actually from "prefer" to "require" here. "prefer" as a default is a trap for users. There were discussions about that not long ago but this gave nothing. I believe this should be discussed and find a common agreement to be implemented by libpq and all the drivers, including a single naming scheme for the parameter and possible values. Opinions? I think that we don't need to have anything complicated here: let's have at least a connection parameter, and perhaps an environment variable which enforces the type of the authentication method to use: scram-sha-256, md5, etc. I don't think that there is any need to support a list of methods, any application could just enforce the parameter to a different value if the previous one failed. Categorization is something that can lose value over the ages, something considered as strong now could be weak in 10 years. By supporting only a list of dedicated names users have the same flexibility, and we just need to switch the default we consider safe. Controlling SSL is already a separate and existing parameter, so I don't think that it should be part of this scheme. Having documentation giving a recommended combination, say "authmethod=scram-sha-256 sslmode=require" would be enough IMO. If the parameter authmethod would rather be "authmethods", i.e., a list, I think it would be significantly more flexible. I agree with a list of methods and all the values already existing for sslmode, this might be more than enough, specially if the channel binding SCRAM mechanisms would get a different authmethod than their non-channel binding partners (like scram-sha-256-plus). This makes the list argument for the authmethods, in my opinion, stronger. Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Authentication mechanisms categorization
On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa wrote: > There has been some prior discussion, that we recently continued at > pgday.ru, about what to do if a client wants to use a "strong" > authentication mechanism but a rogue server forces the client to use a > weaker authentication mechanism. This is the case if the client expects > SCRAM to be used but a rogue server just replies with > AuthenticationCleartextPassword, for example. Client drivers will > authenticate using this latter mechanism, transparently (at least pgjdbc > implementation does this, and I believe libpq also). This somehow defeats > the purpose of some mechanisms like SCRAM. Yeah :( > It was discussed to add a parameter to the driver like "SCRAM-only", but > I think this may not be ideal. "SCRAM-only" means that code needs to be > written to prevent every other authentication mechanism, explicitly, which > is far from ideal. Much worse, it defeats using other auth mechanisms that > might be OK for the user. Also, this doesn't consider whether SCRAM is good > without channel binding. > > I think it would be better to make a categorization of authentication > mechanisms and then have an agreement among libpq and drivers to set a > minimum level of security based on the user's request. Some initial ideas > are: > > - Three security levels: Basic, Medium, Advanced. > - Prevents MITM / does not. > - Given this X possible attacks, a matrix of which mechanisms avoid which > attacks (something similar to the table comparing the possible effects of > the different isolation levels). > > This is not trivial: for example, SCRAM may be OK without channel > binding in the presence of SSL, but without SSL channel binding is a must to > prevent MITM. Similarly, are other auth mechanisms like Kerberos (I'm not an > expert here) as "safe" as SCRAM with our without channel binding? The use of channel binding is linked to SSL, which gets already controlled by sslmode. Users won't get trapped in this area by using "require" instead of the default of "prefer". I would love to see the default value changed actually from "prefer" to "require" here. "prefer" as a default is a trap for users. There were discussions about that not long ago but this gave nothing. > I believe this should be discussed and find a common agreement to be > implemented by libpq and all the drivers, including a single naming scheme > for the parameter and possible values. Opinions? I think that we don't need to have anything complicated here: let's have at least a connection parameter, and perhaps an environment variable which enforces the type of the authentication method to use: scram-sha-256, md5, etc. I don't think that there is any need to support a list of methods, any application could just enforce the parameter to a different value if the previous one failed. Categorization is something that can lose value over the ages, something considered as strong now could be weak in 10 years. By supporting only a list of dedicated names users have the same flexibility, and we just need to switch the default we consider safe. Controlling SSL is already a separate and existing parameter, so I don't think that it should be part of this scheme. Having documentation giving a recommended combination, say "authmethod=scram-sha-256 sslmode=require" would be enough IMO. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Authentication mechanisms categorization
There has been some prior discussion, that we recently continued at pgday.ru, about what to do if a client wants to use a "strong" authentication mechanism but a rogue server forces the client to use a weaker authentication mechanism. This is the case if the client expects SCRAM to be used but a rogue server just replies with AuthenticationCleartextPassword, for example. Client drivers will authenticate using this latter mechanism, transparently (at least pgjdbc implementation does this, and I believe libpq also). This somehow defeats the purpose of some mechanisms like SCRAM. It was discussed to add a parameter to the driver like "SCRAM-only", but I think this may not be ideal. "SCRAM-only" means that code needs to be written to prevent every other authentication mechanism, explicitly, which is far from ideal. Much worse, it defeats using other auth mechanisms that might be OK for the user. Also, this doesn't consider whether SCRAM is good without channel binding. I think it would be better to make a categorization of authentication mechanisms and then have an agreement among libpq and drivers to set a minimum level of security based on the user's request. Some initial ideas are: - Three security levels: Basic, Medium, Advanced. - Prevents MITM / does not. - Given this X possible attacks, a matrix of which mechanisms avoid which attacks (something similar to the table comparing the possible effects of the different isolation levels). This is not trivial: for example, SCRAM may be OK without channel binding in the presence of SSL, but without SSL channel binding is a must to prevent MITM. Similarly, are other auth mechanisms like Kerberos (I'm not an expert here) as "safe" as SCRAM with our without channel binding? I believe this should be discussed and find a common agreement to be implemented by libpq and all the drivers, including a single naming scheme for the parameter and possible values. Opinions? Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
