 I'll talk about features that we have introduced in 5.7, it's address for security. This is a powerful statement, it will be common for each and presentation you see. If we are to categorize security features that are part of 5.7 release, we can broadly classify them in four areas. User management related features, activity control related features, encryption and communication security, and the attempt to make the installation secure by default. I'll go over each of this category and list the features and explain a bit in detail. With user management, we have password rotation policy support and ultra user enhancement. With the release of 8.0.0, which was done last year September, we have support for scale roles as well. Sanjay goes some part of it already. What is password rotation policy? With 5.7, the ultra user statement now supports various levels of control on when password would expire. For example, if it's a non-critical account, you can set that the password will never expire and user can continue to use the same password happily forever. There can be a server-wide default, which is controlled by a global variable called default life time. Let's say if it is set to value, this will accept the value in terms of number of days. Let's say it's set to 10 days, so after every 10 days, the user's password will expire. If you want specific control at each user level, you can specify the interval in terms of number of days where the password will expire. The ultra user support is now enhanced in 5.7. Previously, it used to be limited to locking the user account and password expiry. Now you can change the credential, something which was not possible in 5.6. You can change the authentication plugin which is used by the user. We support plug-able authentication. Now with ultra user, you can change and tell system to use another authentication plugin altogether. The certificate details associated with user can also be changed along with the resource allocation and, of course, temporarily locking the user account which was in 5.6 possible as well. Apart from these features, there are certain ancillary features like making the server offline or super revamp remote, which helps the management of server. It allows only the privileged few users to go in and make the operation, whereas buying all of the users to use the data. With ADR, though, we now have support for SQL roles. It provides an easier administration. This will seem to less complicated ground structure because your roles can be used as a privileged container which you can grant to many users. And it is also possible to create a hierarchy of various depth as per the user's need and you can combine various roles and create a combination of roles as well. There is a feature for role activation, whether it is an explicit bicep role or whether you want to activate the role by default at the time of connection. All the features are also pushed in 8.0, so to give it a try, it's a great feature and it would be great to have your feedback as well. Okay, so that was about user management for activity control. 5.10.7 comes with a plugin which allows you to post a defense against the brute force attack. We have a plugin called connection control. It can be configured to trigger an incremental delay after a fixed number of consecutive failed attempts. So let's say for a user account, it's after three consecutive failed attempts, the server will start introducing a delay with each failed attempt, like one second, two second, three second increment in nature. And till the time when the user provides the correct password, this delay will keep on increasing. It's highly configurable. You can configure the threshold after how many failed attempts you want to trigger the delay, what's the minimum amount of delay, what's the maximum delay that you want to put in. And it also provides the statistics for the EAs in terms of information came on table so that you can see what are the status of various users at any given point of time in the returns. For encryption and communication security, 5.7 comes prepared with a key ring support. This is in terms of a plugin. And in ODP table space encryption, we have enhanced communication security support for TLS level 1.1, 1.2 as well. And the AES encryption enhancement which we have reported of course in 5.62. So this is an overview of the in ODP table space encryption. Inside the server, we have a plugin and services infrastructure which can talk to any key ring backend server. In ODP, which is part of the server, can communicate with the plugin and services infrastructure to obtain the key and input the tables using the key provided by the key ring. Now, the key ring backend can be anything, it can be a flat file system where you used to show the key or it can be a proper KMIP compliant keyword server based on the plugin that you have. And it can store keys from the database. Once the data is started, it fetches the key from the keyword, passes on to VinoDB which uses it for table space encryption with two level encryption support. We use a master key of 256 bit to encrypt the table space level keys and the table space level keys then again are used to encrypt the data. And we also introduce support like key rotation which will generate a fresh master key and re-entered each and every table key to get rid of the old key and other things. Now we support something called SSL mode which is an evolution of the traditional SSL option in the master client side because in 506, the option SSL on the client side can either be turned on and off and even when it's on, it's not guaranteed that your connection will be always encrypted. So we wanted to improve that. We wanted master client to say that don't connect to the server unless the connection is encrypted. So we now have a more expanded version of SSL options called SSL mode which can take various value from disabled, preferred, required and with varying degree of support, it will either don't use the SSL connection, it will try to establish SSL, it will enforce SSL, verify the identity of this, verify the CES sanity or verify the server's identity. On server side you can now say that don't accept any connection unless it's secure. So server can say that it requires secure transport and all the plain TCP connection will not be allowed and only the TCP SSL or the socket connection will be allowed to connect to the server. Similarly on client side you set SSL mode to required or higher and you get the SSL enforced again. The AS encrypt decrypt function provided a fixed key size and ECB as a block mode support. This was very limiting. So now we do support various bit size for key and we also support various level, various block encryption mode based on the library against with the service compiled. If it is compiled against OpenSSL, we support a range of block mode encryption which I supported through OpenSSL. If it's SSL, this list varies. So you can now set a session level variable called block encryption mode. Specify the key bit and the encryption mechanism to use and you can use any AS encrypt decrypt to start using that mechanism. Okay, so last part. So we are actively trying to make the installation secure by default so as to close any loophole it will allow potential attacker to compromise the system. It is an on-wing effort and the first part of it was delivered in 5.7. We now support encryption connection by default. What we try to do is the MySQL server tries to generate certificate at server startup if it is not present or through a separate utility so that server comes prepared with the DLS certificate. Client now attend TLS connection by default. So if server supports encryption and if client tries to connect with SSL you are guaranteed to have an encrypted connection. There are a few other enhancement related to various degree of errors and logs, details in the server log related to CA status and the possible reason for TLS failure. We no longer generate a range of root accounts as a part of our bootstrap process. There is a single root account generated with a random password and the password is expired. So we should change the password to something which is more secure. We also have password relation fully installed by default so it enforces certain restriction on what and what cannot be in the password. Packages are more secure now. We don't have any test and demo data with this shift with the server so that reduces static surface. Secure file preview was the option which can be used to restrict the import and export location from which the data can be read or write. It's disabled by default now. It has to be an exclusive choice that whether you need to whether you want to read or write from the location apart from the data directive. So now that's about it. Thank you. I have questions. Sure. The last line. The last line. Possible of disabled data import is put completely. It's possible 5.7. It is. I can restrict my server. Nobody can take out the data from you. So what do you read? No, not the export utility. So we support something like select start from into out file or insert load data from a bit in file. So if you set secure file to null, both these operations are not allowed. And that is the default. Now it's the default. If you want to relax that restriction, you have to specify that it started in from a particular directory or write into a particular directory. Thank you. I have another question. About the stable-level encryption, what is the performance grid of means? We haven't seen any significant. Any significant? No. Is this possible? It means for certain columns I can encrypt from a table. Is this possible? Not as a transparent encryption. You can use AES encrypt or AES liquid function for that particular column when you are reading or writing through that column. Sorry. I just wanted to make sure. So all the features that you have mentioned are available in the open source version? Everything is available in open source. I mean, for key rings we have enterprise only features, but the basic key ring infrastructure is available in community versions. Thank you. Is this possible? Make sure you have all the features. I just wanted to check. It's our call. It's our call. It's our call. Actual case. Actual case. I had a situation whereby one guy had lost his password. It was a little way of password. And there was a change of players over time. So therefore the new guy definitely did more and said to do a technical refresh, which means he had to move this over to the other place and he could not break back. Is it easy to recover the password should he need to do something like that? Okay. So I will talk in terms of the defaulting authentication that the server comes with, like native password or sharp root cases. And the password storing mechanism is plug-able in 5.6 onwards. So you can choose the authentication method that you want to use. For example, you can use spam libraries. If you have your LEDAC support, you can configure server to use the LEDAC password and everything. But for the default methods, we do not store password, we just store the hashes. So once server is only aware about the hashes and server cannot retrieve password from the hash. What you can do is root user can use altered user to reset the password for other user and expire it at the same time. So let's say user who lost the password will do altered user who identified by any CD password expired and you give the CD to the user. What about this way? As I said, since it's a hash, there is no way to retrieve the password once it's lost. So if the password is lost, because we do not store the password. If we store the password in a format which can be reverse engineered to construct a plain text password, it also opens up a window for attackers. If they get hold of it and if they get hold of the encryption mechanism and the encryption key, they have a plain text password. So there is no plain text password store on the server tables. You just store the hashes. They are cryptographic hashes. They have one-way functions. Once you have the hash, there is no way to go back. So if the password is lost, DPA has to come in and replace the password. Like I said, there was a change of player system. And the thing is, the guy, we had to call him up from his new job and ask him, do you remember the password? The guy said, no. That really happens in real life. So was it the root password? No, it was a middle-ware password. What is your password? The way middle-ware works is that normally you do not lock in. The system automatically locks in for you until you have to do something like a technical refresh. Then you have to remember whatever middle-ware password it was which could have been years ago. I understand. But call it a security feature or... We don't want to store the password in a reversible fashion. That's a conscious decision. If we do that... Is there a way to manually overwrite that? It is. You can use it or use it. There is no way to overwrite and say, okay, store the plain text password. There is no way. No, I didn't mean it that way. In the situation whereby it's already happened we've forgotten all the passwords. We made the system as secure as possible at the time that we thought it was wise during the deployment. But it backfired because several years later when we had to do a technical refresh everybody forgot all the passwords. We learned a guy who set the password in the first place. You can restart my skill in passwordless mode. Skip, crank, say mode. Of course you should try to not have it in the network. It's a very risky thing to do. But there isn't a possibility. Skip your own table. It will not load any password. It will allow you to bootstrap the server as if you trust this environment. It will allow anyone to log in and change any of the passwords to anything. But again, it's very, very risky. I recommend you use in-stift networking as well. Yeah. I have a question. First of all, as you mentioned, GB is in read-only mode or offline. You can set it in offline mode. Yes. Can you leave this in some way? So it's a new option introduced in 5.7. It's a global option which can be set at any time. Once you set this option, nobody but the user with super ACL can connect with the server. So if there is a critical maintenance that you want to perform and you want to make sure that your regular application connection does not connect with the server, you set it to offline mode, perform all the script tasks that you want to do, and then revoke the offline mode. Is this possible? Can I put my whole data in a read-only mode? It is already possible. There is a read-only mode already there in 5.6 as well. But the offline mode is different. It will allow super to do anything that super wants. But it will not allow any other connection. Whereas in read-only, all the connections are allowed. You can select from the databases tables. But you cannot change that. Whereas offline is just specific to a particular set of users. Yes. We have offline read-only also combined together. That means... You can? Okay. Non-super users can read only. But super users can read and write. There is an option for that as well. You have read-only which will allow regular users to just read and super to do whatever they want. Oh, okay. Okay, so this is an enhancement over that which will not even allow super to do so if you want to put it one more level. But even 5.6 supports read-only. I have one question about... Just when you mentioned about the... What was that? Does this brute force attack? Yes. Yes. So if let's say there are few... Not just one connection but many, many connections coming in. Just one user. More than one user. Would it... Oh, there wouldn't be any applied connect. If you have a single user account which is connecting through, let's say, 10 connections, it will identify, it will contact. I mean, let's say somebody is trying to organize a DDoS and connecting from different posts to the same user, I mean. It will detect that at 10, 10, it will lock the user. Okay. That were the delay. Let's say if it's increasing, will it affect the performance of the database or it shouldn't, right? It will keep the connection handling thread in wait state for that much amount. But other threads will not make that. Okay. And of course you have... You have show process list. Identify those connections, you can manually kill them as well. The idea is if you reply soon enough to the attacker that your password is... I mean, password does not match or there's an authentication value, they can start with another password. So we have to keep the clients waiting for service reply before you say yes or no. Okay. One last question. Sure. Is there any future available like auditing? Which user is changing the data on which data? Can I... Yes. Auditing is available. So we have... The way I'm asking once is we have very many types of plug-in interfaces where anybody can write their own plug-in, which others to certain specific APIs and can plug it in. So auditing is one type of plug-in. We have a product, but it's not incoming to you. Is that the enterprise audit plug-ins? Yes. So you're saying you're not supposed to... Yeah. So, I mean, I did not cover because we have the enterprise audit plug-in. But there is one. Thank you. But, well, now that you have mentioned, the connection control plug-in makes use of auditing APIs. This plug-in, that uses the auditing API to figure out where to interview students. Okay. So no more questions? Right. Thank you. Thank you for your time.