Re: [HACKERS] Authentication mechanisms categorization
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: [HACKERS] Authentication mechanisms categorization |
Дата | |
Msg-id | 99557809-81ce-a50c-684d-beb29d1d1f58@8kdata.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Authentication mechanisms categorization (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Authentication mechanisms categorization
(Michael Paquier <michael.paquier@gmail.com>)
|
Список | pgsql-hackers |
On 14/07/17 11:09, Michael Paquier wrote: > On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa <aht@8kdata.com> 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. Hmmmm 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Michael PaquierДата:
Сообщение: Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server
Следующее
От: Michael PaquierДата:
Сообщение: Re: [HACKERS] Authentication mechanisms categorization