 And I hope you have your coffee yet. We get a whole bunch of, sorry, I have to stand here, I hear. We get a whole line of talks lined up for you. We start first with Kristof Munch-Tegeter. Yeah. Is that correct? Okay. So he's going to talk about all the different client authentication methods we have and all the ins and outs, especially what you shouldn't do. So you've got some more stories. Okay. Yeah. Good morning. I'm Kristof. I worked with second-poderant as a consultant. And I do most of my work at customer sites, helping users figure out how to configure the Postgres, how to tune the Postgres for performance, and so on. And one of the things most people need left is authentication. And so, yeah, that's what I get some of that more out in the open. It's all the documentation, but nobody reads the documentation because documentation is boring. Let's find it out ourselves. So, yeah, that's that. Authentication. Why should we authenticate? It's complicated. You have to configure it. It's inflexible. Nobody knows when my database is. Nobody will target us. That's all the stuff one hears. But really, people are out for databases. For example, the Philippines election database was more or less stolen or no password database error. That's the thing we are talking about here. And that even became a business model. People are, yeah, I can't say hacking databases. They are just connected to the databases and copying out the data, deleting the database content and demanding ransom money for the people to get the data back. And that goes into thousands of databases. In fact, that was MongoDB, but not the only one. And the hackers who did this just automated the world task, find MongoDB databases, connect to them, extract the data and leave a ransom note. And 27,000 databases in just a few hours is some number. And as I realize there is only a limited number of MongoDB databases, they diverged their business model and moved on to Elasticsearch and some other databases. And really, we do not want to have Postgres on that list, too. Yeah, what do we do about that? So without authentication that's not the kind of open data we want to have. We do not want to pay those criminals. Sometimes there are even regulations. For example, if you are handling payment data, you have to comply with PCI DSS or even more personal data like health-related data where you have really strong authentication and you have regular audits where they really check if you have good authentication configured. And nobody wants to explain to his boss, yeah, we got our database hacked and now it's gone. So yeah, what do we do? We cannot even hide our database. There are specialist search engines to find some kinds of products. This is a screenshot of Shoden. This shows a MongoDB database. When I searched on Shoden for Postgres database, they were all locked down, which is a good sign. There's another search engine, ZoomI. You can really search for the products and for certain properties on those products and get the IP addresses, which I blanked out up there and see that this piece of it here shows that this is one of the hacked databases. So yeah, we cannot even hide our database. So we have to secure our database. The first thing of course is we set up network security, set up firewalls. Anybody who can't connect to our database can't hack it. That's quite easy just to get it out of the line of fire. Another plus point for Postgres is here, it listens on localhost by default only. So it's not that easy to get it on the net accidentally. You have to open it up to the right network. But on localhost it's not always usable. You want to have a database server which listens to some connects from the outside. So eventually you have to open the listen addresses parameter to get your Postgres on the network. Other things to remember is using fine-grained access control if you run your application as a database super user and there's nothing the database can do to defend itself against deletion or something like that. Always use a regular user which has only the needed permissions on the database. Of course application itself has to be secured also. For example, SQL injection, we can't do anything in the database against that or have very limited ways to defend against SQL injection once SQL comes to the database. The point we want to talk about today is authenticate all the regular users. So you do know who your users are and that's only your users who are connecting to the database. Some definitions about that. We have identification that is more or less a declaration of identity. So if the client connects and says I'm user 42, that's his identification. The authentication is a proof of identity with something you know or you have or you are. For example, passwords. In some way, client certificate and so on. Something we have is for example with two factor authentication if you have this Fido keys, USB keys or even the Google Authenticator app on your phone and what you are is biometrics which doesn't really apply for databases because the database is really scanning your eyes or reading a fingerprint. Some people say it's what you're used to know and what you have forgotten. For example, the passwords or what you had and have long lost. For example, the token or what you have been. For example, if you have injured your fingers and the fingerprint reader can't read them anymore. So it's always a little interesting what you can use for authentication. Authorization is the next step in the chain that is allowing someone to use that object in some way to have some action on that object. Postgres and all other databases do that because this is a grant and revoke and so on. And role of security is in the same area but we are not talking about that today. And what you always want to have is some kind of audit log who connect, who did what. Of course we have to set that up correctly. Perhaps you can't log every select but perhaps you want to log changes to the database so we do know when something was changed and who did change it and what was changed. That's what the log connections parameter is for, PG audit and some other parameters. But today we'll focus on the authentication but because that's enough for today. What can we use for authentication? What secrets do we have? We can have shared keys. It's like both sides have to know the password or at least something derived from the password like the password hash. That's a shared key. We have asymmetric keys like client certificates where the server side doesn't need to have the private part of the key. Only the client has a private key to the certificate and that's one of the criteria to select your authentication on. How do you change secrets? If you have to roll over your authentication perhaps because someone left your organization you do not want to have every former admin to have all the passwords to your database so there has to be some mechanism to change passwords and you do not only have to change it on the database side but you can change it in the application too of course. And always remember do not put your passwords or your private keys on GitHub. There has been an incident a few years ago where you really could use the GitHub code search for begin as a private key and find tons of SSH keys and certificates, private keys and so on in GitHub and you still can use regular search engines to find private keys so you do not want to have your private key in some search engine or accessible by someone. It's easy to do, just have it in your code and get it, get commit, get push and move it on GitHub. So yeah, careful with that. Do you back up your keys or don't you? If you do back up your keys you can always recover quite easily just restore the backup and everything is there but on the other hand suddenly all your passwords are in your backups so you have to guard your backups against unauthorized access. And if you do not back up your secrets how do you restore your secrets if you have to restore your database? Restoring databases is sometimes not an easy task. There's a talk about later today and everyone remembers the GitHub incident from last week so yeah, that's the topic for itself. One way out of that are hardware security modules. Those are from small USB tokens to one or two rec units devices which have private keys stored in them and only do operations on those private keys but never ever release the private keys to the application so you can preload this module with the private key and plug it in and if that module is stolen or lost you note that the key cannot be copied out of that but on the other hand if that module is the only place where your keys live what do you do if the module is lost? Those small USB tokens are quite easily lost or if it just stops working, it's broken and hardware always is broken after some time sometimes quite short time so even there you have to consider how to roll out new secrets or perhaps if you can keep a backup of your keys somewhere out of the module or have a second module or something like that. Security of your authentication what you have to know about that we have passive attacks on authentication that is if someone listens on the network and watches the traffic go by and grabs the password from that authentication info of the net and of course all other traffic if all your attacker wants is to have a look at the database perhaps it's enough to listen to the traffic he doesn't even have to break the authentication for that and there are active attacks when traffic is redirected that's not that common in your own data center but sometimes internet routing goes wrong or someone injects wrong routes and suddenly they can intercept authentication it's especially interesting on wireless where just everyone can set up a base station so nobody does clear text on the Wi-Fi anymore luckily and of course anyone who can intercept traffic could also modify the traffic so there are some quite interesting attacks in there as Martin Zicker once said there is no safe authentication unless you authenticate against who you are authenticating first so you do know who you are authenticating so that do not just play man in the middle and relay your password or something like that to the target so getting to the point in this Postgres we have a very flexible and highly configurable authentication system here it's even well documented but as I said who reads our documentation everyone just uses what's already there we have depending on how Postgres is installed up to 13 different authentication methods and you can configure them per database, per user per source network so perhaps your production servers need the one type of authentication and the admin network has another kind of authentication you can even switch that around by connection type the configuration for that is in the PGHBA that's a host-based authentication configuration and that file is always for each connection checked from top to bottom and the first match wins so that's the order you have to be aware of and I've seen some of these files get really big with dozens up to hundreds of different connections configured in there and if you ask the admin if that's really needed you have things like we don't know but nobody will take it out because something might break so have documentation on your entries and check if they are really needed or if the application has gone away or if that was some temporary measure just to keep only those aspects in there which you really need and a side note all the users have to exist in Postgres we have always to create user create role in Postgres we do not have any user auto-creation or something like that we only delegate authentication to some external provider or internal so we cannot create users automatically because that would extend to user auto-deletion and we can't just delete a user from Postgres because that user might still own some objects and we can't have objects as an owner in the database how does this authentication configuration look like for example the entry for IPv4 local connections the first column is the type of connection host says it's all network connections and we have host SSL there for connections of IP with SSL on that and we even have host no SSL which are connections without SSL the local exists on Unix platforms only that's a local Unix socket and we do not have that on Windows the second column is the database there are a few special keywords in there all databases we can add a file notation that reads the list of databases from some file the application is the keyword for application connections the same role is the keyword to get the same database as the role who is connecting the third column is the user column again some special keywords are all is again all users we can have the plus syntax for groups and again the add file syntax to read the list of users from a file if for some reason someone wants to name his database or his user an all or a replication or something like that you can always double quote the strings so they lose their special meaning if you have spaces in database or user names you have to double quote them so they can get passed out of there for non-local connections we have the source network that can be IPv4 or IPv6 this is the IPv4 syntax you always have to add a net mask either as this or as a dot in what notation the IPv6 syntax is the same you have the network address and the net mask and the last column is the authentication method in this case it's MD5 and we can add some options to that and we have a look at what we can do there some special cases we have this pg-ident con file that allows a mapping of external user names to Postgres user names we'll need that for example with Kerberos or SSL and we can have a different map per the hba con line the parameter in pg-hba con is the map which selects the map in the pg-ident con and we have full regular expression support in that file so we do not have to add a line for every user perhaps we can do that by regular expression and some examples we have the map name which goes into the map parameter and we have the system username that's the username which is delivered externally to Postgres and the Postgres username for example this is for SSL connections we have the test user from external to SSL user in Postgres or with Kerberos, I've added a Kerberos map here we have always the user names with realm we expect the local part from the realm like this with regular expression and just have the first match here it's not in Typhus that there is no closing the slash is really not in the system we only need the opening slash to mark the regular expression but we do not need or do not have the closing slash so for the second part the authentication mechanisms what do we have there the most well known perhaps is trust but there is nothing like trust trust is no authentication at all it just trusts what the client says he is that is we are just using identification there is really no password nothing is just we have the user they want to connect to the database from the right network so obviously that is not good for servers this is exactly the configuration which leads to the no password error which leads suddenly to the country's election database so yes do not use this on servers trust is fine for example for testing when you are running a regression test from the Postgres source code it's easier with trust sometimes in some embedded systems when you do know that the database will never ever be connected to any network but as we know all those little things today suddenly grow network interfaces and a piece of the internet of things which should never have been connected to the internet so very careful with trust in some configurations trust appears in the initial pghba code when you first initialize the Postgres cluster that's somewhat fine because that's just a new installation which does not listen on the network but please check if that's in there and change it to something more secure identity is the second mechanism which sometimes pops up in the configuration the idea behind identity is that we connect back to the source host to the client host and ask that for the owner of the connection that's identification protocol from RFC 1413 so obviously from the low number we see quite old RFC users might still know that protocol it's not that common today anymore luckily that means that we have to open an additional TCP connection on every connection from a remote host which obviously is some overhead which we could save and it relies on the security of the source host the source host can say anything about his users so perhaps not a good idea even the standard itself says the identification protocol is not intended as an authorization or access control protocol so perhaps not the best idea for authentication quite often we see peer authentication that works on local connections only that is the Unix socket connection with connection type local we can read the system username from the Unix socket and do know which Unix user is connecting to the database this is quite a nice idea because everyone who can fake the username from the Unix socket has already compromised the system and can most likely just compromise the Postgres as well because he is already a root that's great for local administration many deduces distribution puts that as the default for the Postgres user on the local Unix socket so all maintenance jobs can just connect to the database so you're running locally it's as secure as the host itself is but as it's only on the local socket it's of limited use for a database server because a database server almost always has remote connections and we can't use a peer for remote connections in fact if you have a peer keyboard on a host or something like that connection it gets converted to identity and then we are back at the previous slide so that's it's fine for local connections but not for remote the next thing in reject as the name of this authentication mechanism says that just blacklisting we explicitly reject this connection no matter what you could see in authentication we can use that to reject some users or one user of some set of users and allow all the others with a later line in pghbhconf we can also use that to block access to the database due to maintenance we can just drop the reject line in pghbhconf and do a postgres reload with listen addresses we would have to restart postgres but we can just reject all external connections and have the database server locked up without restarting the database server as we do not get authenticated by this I call this a non-authentication method it just makes sure that nobody can connect if you matches that line we have a little less loan luckily the password authentication method with the password keyword in pghbhconf that's password authentication we have the password hashes stored in postgres except if you have to turn password encryption off in postgres code but you shouldn't do that and the table where the hashes are stored is pghout ID authentication method sends the passwords in clear over the network so everyone who has a sniff on the network can read the passwords on the network so do not use that because we have md5 which at least sends password hashes over the network so you can't just read the password of the network and md5 that's this one from the client side nearly the same we have again password authentication the password hashes are stored in postgres same table again stored as hashes unless you switch password encryption off which you really shouldn't do on the wire we have this twin md5 and the hash of password username plus salt the salt is switched on every connection salt is a 4 bytes integer so if you do the math you get a replay attack after about 2 billion connections when you have about 50% chance exactly this salt has been used before and then you can just reuse your hash which you have captured from the network earlier 2 billion connections is quite a lot in postgres but on the other hand we are using md5 hash even in this construction and md5 has been broken for quite some time now it's quite easy to just construct something which doesn't value so perhaps not that good anymore but it's still better than plaintext password we do know that sometimes people who are or companies who are under regulations like PCI DSS get problems with their auditors because they say they have md5 in the configuration that's not allowed anymore in most cases the auditor doesn't really understand the post authentication but he sees this md5 string and he just knows that md5 is not allowed anymore so sometimes you need something different and we are still not authenticating the server so if anybody manages to do a middle attack on your connection they can just take over the connection next one this is a lightweight directory access protocol if you look at the syntax it's not that lightweight anymore but if you have ever seen the x500 directory access protocol this is an improvement we are authenticating against an LDAP back end the LDAP server is not included in postgres so we have to have some external infrastructure for example if you have some directory server in your organization you can use that for that or you can set up your own LDAP server and we have two methods of authentication we can do the simple authentication the simple mode where we use the credentials we get from the network from the client to authenticate to the LDAP server and if that succeeds you are fine and we have the search and bind mode to the LDAP server with our own credentials with the postgres server credentials and then search for the user matching the username and the password given from the client we can use a TLS connection to the LDAP server which is always a good idea but we can do start TLS only that's defined in the RFCs we do not do LDAP over SSL the difference is that the TLS connection is like SMTP start TLS we do a connection first then send the start TLS to start the SSL negotiation on the connection the other mode LDAP over SSL is where we do SSL negotiation first and then start the LDAP protocol that's not in the standard but unluckily some servers only do the mode which is not in the standard and do not support the mode which is in the standard thanks Microsoft so sometimes you have to look out what to do here and there's one big problem with the LDAP authentication method we have to send a database password from the client to the server so the server can use that password when querying the LDAP server we cannot send the password hash because the password hash is not what's stored on the LDAP server or perhaps it's not stored in the right format so we use the clear text password on the database connection so we really want to use an SSL or TLS for the Postgres connection so that we get the password out of the clear in fact without the TLS for the Postgres connection this is slightly worse than the MD5 mechanism because in MD5 we have at least a solid hash of the password on the wire and here it's suddenly clear text again but it doesn't have the MD5 string in the configuration which makes some auditors more happy because as I said they don't know Postgres authentication we had this one customer who was the auditor really recommended using LDAP authentication over MD5 authentication so yeah, we are aware of that there's PAN, the Plugable Authentication Modules that's mostly Linux only technique but Linux inhibited this from Solaris back in the 90s I think and those modules which are kind of plugins for authentication and sometimes even more if you are using PAM for Shelf you do a session setup with that the configuration files are in etcpam.d or something similar in most distributions I know it's etcpamd even if you are using PAM we cannot access the system passwords because the system passwords are stored in etcshadow which is readable by root only if you try to run it in root and you really shouldn't make etcshadow more readable by any other users the great advantage of the PAM is we can use some modules which delay the next connection after a failed authentication attempt we can have a counter which locks the account after a number of failed authentications which is always really great but again we have the t-text password on the network because we can't really know how the PAM module will use the password to authenticate do we have a t-text list, do we have some special hashes do we connect to another server whatever so again use tls for the POSCUS connection to get the t-text password of the network and there is GSS the genetic security services AP these days used for example for Kaboros that is for POSCUS trust we use Kaboros 5 the Kaboros infrastructure of course the KDC and so on is not included in POSCUS if you ever see Kaboros 4 in the wild that's really outdated for about a decade now with Kaboros we get a whole new bunch of technology we are suddenly talking of the alms which is something like windows domain mostly we have principles which are the username tickets which are used for authentication the ticket granting ticket which is used to get the application specific ticket and so on so that's really a whole bunch of things which suddenly have to set up and the authentication flow is that the client first authenticate authenticate to the key distribution center the KDC and gets the ticket there we have the service server the so called which is our database server because that's providing the service database that also has to authenticate to the KDC so the KDC is a source of trust in the system and we need accurate times across all systems if the times queue is too big the tickets just won't match anymore and we have periodic ticket renewal that is every per default 8 hours these tickets expire and you have to get a new ticket either by renewing the old ticket or by creating a new one all of these things are not handled by the Postgres library itself your application has to handle them which doesn't really make things easier for the application but on the other hand we get the t-text password of the network we are only handling the tickets and the tickets are themselves encrypted and all entities as the client as well as the Postgres server are authenticated to the KDC and everyone has to trust the KDC because that's how Kerberos works that looks like a great idea except for all the fast with the Kerberos infrastructure and of course the Kerberos thing is really flexible on itself we can have the KDC store the passwords in its own database or on LDAP or something else the client can use passwords to authenticate or use a PK init mechanism which is a public key mechanism or a bunch of other things there are GitHub files so called for all non-interactive processes an interactive user can always enter his password so the application can read it from there which is again a store secret so that's one of the cases where you have really to think if you want to back up that file or if you are recreating it, if you have ever to store your database and as the Kerberos principles look like this we have the username add and the real name in almost all cases we are using pgident to map the system username the Kerberos username to some Postgres username like this regular expression here on the Postgres site that's really easy to configure we just have to add a keytab file Kerberos server key file is the parameter in Postgres.conf and in the pghba.conf we have just the GSS keyboard here and we have to add the album that we are authenticating against and the client connection has to add the Kerberos server name so they get the server's name right once we have the Kerberos up and running which can be a task on its own the Postgres config is rather simple next we have a little client certificate of course it works only for SSL connections so on host SSL and the client verifies the server certificate and the server verifies the client certificate this requires of course public key infrastructure which is not included in Postgres of course you can always create some user certificates with open SSL and signs but that doesn't really scale so there is real CA software like tiny CA open pkx and something like that which you should use for that the minimum server configuration is that we switch SSL on add the server certificate and we need the user CA which signs all the user certificates I do not recommend to reuse the server CA for the user certificates as that's another entity which says which are quite distinct from servers but we do not need to buy some expensive external CA services we can just roll our own CA for the users and then we have the client connections where we have to add the certificate and the SSL key so the SSL authentication works again the private keys are really important secrets you do not want to leak them so back up or not to back up client certificates expire but you can just change the certificate and on the next connection the new certificate will be used the server certificates and the CA's expire too to change those on the server side you need to restart Postgres to revoke a client certificate if it gets lost or something like that the certificate revocation list the SSL CL file per meter in Postgres before Postgres 10 that is for all Postgres versions changing the CL requires a Postgres restart which is not that elegant but the patch is already in so that will be resolved later this year and we map the common name of the client certificate to the Postgres user like this is the common name the CL of the client certificate is test user the Postgres username will be mapped to SSL user like this some other mechanisms radios, remote authentication, Dalian user service as the name says that's mostly in telecommunications environments I've never seen that outside of telecommunications equipment then there's SSPI that's a security support provider interface so it's only available in Postgres on Windows that's a single sign on mechanism with Kerberos and Foilback via ET11 and we have BSD that's an open BSD authentication framework that only exists on open BSD but it's basically like the plug-in authentication modules some final considerations for authentication on TLS if you're using TLS the default cypher list is much too broad it's medium and high so we get some goodies like Arc4 and D5 which really shouldn't be used so you should get a better cypher list but for example if you're using java software make sure your java speaks TLS cypher list you select it you can and should generate your own dvh element parameters for example the open is a Gantt h because the built-ins are defaults which are used in 20 years about now recent Postgres with recent OpenSS even supports ECC as ECC DSA so you can use elliptic curve certificates which makes the keys much shorter in any case setup for a new connection is much more expensive than without TLS because we have to do all this key exchange thing and the asymmetric keys which require quite some compute power but once the connection is up we have only the overhead for the symmetric cypher which really isn't that high for modern CPU anymore if you use a connection pooler you have to be aware the client can only authenticate to the pooler PG Bouncer has a mode where the client authentication is passed through to the server and the pooler always authenticate its own connection to the database forwarding authentication works only with plaintext passwords so not that elegant and if you are using TLS the TLS connection gets terminated on the pooler and you can use another TLS connection between the pooler and the database or have a plaintext connection between the pooler and the database depending on the setup if the pooler is running on the same host as the database the plaintext connection to the database won't hurt but if the pooler is on its own host we have to set up a second pair of certificates summary always secure databases else you have one kind of open data always authenticate your clients that protects from the no password error which leaks 100 million database entries and authenticate the servers for example with server certificates the minimum you can do is using passwords and use TLS connections whenever possible because that's the cheapest way to get all the plaintext of the network and if you are using all certificates the server certificates should be verified to questions if you have any questions let me come to you with the microphone because we are all recording this and everybody wants to hear you Hi, first beautiful talk, thanks a lot I have a question, I found that when you setup a new Postgres database and you configure the PGHP8 file it's very easy to create a setting where you think you have a username with MD5 hash set but it's actually no password because you accidentally switched one tab to the right so it's a very sloppy file parsing and it doesn't give a warning is there a way to make this trickter? Good question, I always use spaces to make the beginners error so I would wish to have a simple security check, is it possible to log in without any password in your database? You can always twizit with psquares command line client and just give no password or connect and check whether it asks for password so I have to test by hand basically if I have some time on the way home Good idea Thanks Any other questions over there? Yeah, thank you for this talk, I agree that config of the HBA is not so nice it would also be nice if we would code check that we could check that a line would never be hit if there is a host or all trust then the first match we could do something nice with that so we might should code that but what TLS version is actually used in psquares and is there something like session resumption or planning for TLS 1.3? There is no session cache right now and we use TLS version from OpenSSL at the cipher list so if you configure the cipher list you get TLS 1.2 cipher and OpenSSL does 1.2 it's all OpenSSL down there Any other questions over here? After that I will come to you Yes, my question is with the Pitchy ABA you can specify the same user for a database What if you are in an environment like shared hosting where a customer wants to have multiple databases can you specify the schema where a database is put in with something like the same user? No, there is a user schema parameter in POSCOS that basically switches the password hashing off which is not really what we want I think you could work with PGIdentMap to get something like that That should work but I've never tried that So there was one question on this side Thank you for your talk as well Are there any plans on OCSP support with certificate of authentication? Can have some problems otherwise I've heard but instead of reloading CRLs? I know that some people are working on authentication stuff for example The CRL reload was added I think OCSP would be next I think it's a matter of developer time You just need to find a developer who has enough time for that because all of them are quite busy It's open source Hi, thank you for your talk as well Question about the client certificate authentication method You said it now uses common name fields from the client certificate to authenticate the certificate Is it also possible to specify the issuer the issuing CA? That happens with the user CA parameter because you have only one CA in the POSCOS for verify user certificates Okay, so you would only be able to use one CA to verify user certificates You could not use different CA's I believe it's only one CA but I've never tried to put multiple CA certificates in the user CA file I would expect it to fail I think Steven has some information on that Steven wants to come on dinner? I'll give you the mic So it's actually possible to have multiple CA's with client certificates We don't currently have a way of specifying the issuing authority I'm not sure who had the question but you can't specify per issuing CA unfortunately It's an interesting idea though I agree that would probably be good especially when you have cross-line CA's and other stuff like that where that matters but we can't today It's just based on the common name So regarding the pghba.com you mentioned don't use passwords because it can be sniffed and the preferred method is the MD5 and that all makes sense I was just wondering why isn't the password which is a little bit weak why isn't that being deprecated or is that something they're talking about because it's the sort of thing a rookie DBA might make and then suddenly you've got very bad news for postgres someone's been hacked I think never no one removes code unless there's a strong incentive to do that so perhaps one should just give a little push on the main list even I before I researched this thought that the password thing was out but oops it's still there Okay, well I mean it's a suggestion because it is something which someone you think passwords sound secure but you can't easily hack them I think perhaps you need that maybe you said password encryption to off or the user schema to on where we can't use hash passwords because password representation on server and host client starts to differ so perhaps it's used there but as I said avoids it at all cost Hey, just you mentioned that MD5 is not good everyone knows the drawbacks of it and it's not made for storing passwords but just to compare stuff so why isn't it replaced with a more appropriate hashing algorithm for verifying passwords People are working on that so I would expect it to be improved in postgres 10 but the patch is passed back and forth and it's not been applied yet but there is a patch and people are working on that I just have a comment the MD5 is not the regular MD5 it's a stretched and hashed what's called recycled one so it's not the usual problems with MD5 just the name Yeah, but it doesn't help you with the auditor and even if it has been improved we should use to something really modern and nobody gets bad idea One more question there I think we have time for one last question Unfortunately that's not a question just a new comment about MD5 I think it should be removed at all and we should use something modern like TLS or something else because just hashing doesn't help for men in the middle attacks and other bunch of all kinds of attacks so I suggest to not use it at all to not use it at all if possible use TLS as I said some small libraries can't speak TLS so it means that in that case you shouldn't you should improve the client expose server to the public infrastructure Yes, of course Alright No more questions I think we are already out of time actually Thank you Christoph I think we got 3 minutes to