from the dev document, i got that opengauss support several encryption type for cleint authentication:
md5
sha256 (as default)
local is a Unix domain socket. host is a common or SSL-encrypted TCP/IP socket. hostssl is an SSL-encrypted TCP/IP socket. hostnossl is a TCP/IP-only socket.
authmehod-options is an optional parameter. Value range:
As i know that md5 is not safe enough?
so why opengauss still support it, which authentication encryption type is recommanded ?
Use MD5 only for compatibility with legacy applications and data.
Sha256 is recommanded.
for your question, i guess openGauss have to sovle compatibility issue.
that is there are many old version deploying in customer's env, they may use the md5 encryption type.
so that openGauss can not delete the type directly.
then use sha256 authentication encryption as default for secure;
use md5 for compatibility, but better make sure use it in trusted network.
Related
I want to implement kerberos authentication for a software where both the server and the clients run on Windows and are implemented in C++.
When both, the clients and the server are on the same Windows domain it is straight forward to use SSPI and I assume this will work also for cross-realm environments.
When for any reason the server cannot be member of the domain this straigth forward approach will not work.
How is it possible to achieve Kerberos authentiaction against a server that is not member of the domain?
If my research is correct java applications or linux use a keytab file instead of implicitly retrieving the key from AD. Apparently SSPI does not support keytab files. Is there a way to use keytab files in this scenario?
SSPI does not "retrieve the key from AD" – the service key is always stored locally, but with SSPI it's the machine account password which was generated during AD join process (and uploaded to AD rather than retrieved from) that acts in place of the keytab. Windows stores the machine password in LSA and derives the key from it in memory, but it has the same purpose as a keytab file.
There may be a way to store a machine password in a non-AD machine (using ksetup.exe), but it is very much a system-wide change – it seems to make certain parts of the Windows login process function as if the system was domain-joined – so I would not recommend doing so, except in a test VM.
Instead, you can use another Kerberos implementation – MIT Kerberos and Heimdal are the two major non-AD Kerberos implementations that come in the form of C libraries (both are Windows-compatible, though their focus is on Linux/Unix-like systems). Both libraries provide the GSSAPI interface, which is similar to Windows SSPI, and both use keytab files for service credentials.
For C#, Kerberos.NET is available. For Rust, sspi-rs seems to be in active development (it isn't just a binding to Windows SSPI but a standalone implementation as well). Java of course has its own Kerberos implementation built-in as part of JAAS although Apache Kerby exists as well.
Most of those implementations support the same keytab format because they mimic MIT Kerberos to some extent (which was the original Kerberos 5 implementation).
Both MIT Krb5 and Heimdal include not just a library but a KDC service as well, though that part won't run on Windows. (Kerby and Kerberos.NET could also be used to build minimal KDCs.)
The above is more important for servers; however, a client can use SSPI to authenticate to Kerberos services without any requirement to be a domain member.
For realms that are AD-based (regardless of the specific server being domain-joined or not), it is enough to provide a UPN-format username (in the form of user#domain) and a password to SSPI; it will automatically discover KDCs and obtain tickets.
The same works for Kerberos realms that are not AD-based as long as the realm is marked as a "MIT realm" either via registry or using ksetup /AddRealmFlags. (The principal user#REALM needs to be specified as username in this case.) Unlike the earlier mentioned case, this ksetup.exe usage seems to have no negative side effects.
I was running running klist on my machine I can see 2 (TGT?) tickets with: Server: krbtgt/DOMAIN.COM # DOMAIN.COM and KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
I understand RC4 is depreciated and all my other tickets are listed with AES256. Just not sure if this is cause for concern?
Does the krbtgt AD account just need to be reset? Is there a risk someone could dump the ticket with the hash and crack it?
Thx
I understand RC4 is depreciated and all my other tickets are listed with AES256. Just not sure if this is cause for concern?
Yes, it's possible that the current keys for the krbtgt principal were created very long ago, before your AD DCs had AES support (meaning there are no AES keys stored for it), and if newer Windows (or Linux Krb5) versions begin turning off RC4-HMAC support, those machines will become completely unable to authenticate.
Does the krbtgt AD account just need to be reset?
Yes, but preferably using the official tool (not by setting a password by hand).
Is the Oracle Encryption good enough to encrypt Network trafic?
Or should I use the SSL option?
Update:
- Network = LAN
- With the Oracle Net manager, you can enable Encryption (AES256 for instance) or you can set up SSL.
Is the Encryption enough? When sniffing with Wireshark the data is indeed encrypted but the Protocol stays TNS. With SSL you get TLSv1.2.
I'm also looking for the option with the leaset performance drop.
As per the general configuration setup of TLS/SSL, you will have to get a certificate issued for the database. Once you have the certificate, you need to put it into a wallet, and then configure your listener to use the wallet. Also, for all the client who wants to connect to the database you will have to give them the trusted certificate and client setup will have to configured to use the certificate for validation.
For native network encryption, you need use a flag in sqlnet.ora to indicate whether you require/accept/reject encrypted connection. In case of server sqlnet.ora, the flag is SQLNET.ENCRYPTION_SERVER, and for client it's SQLNET.ENCRYPTION_CLIENT. Default value of the flag is accepted. This means you can get away without having to configure all client to use encryption for the connection. All you need is to configure the server to use network encryption.
The advantage of native network encryption over TLS/SSL is that you hardly need to do any configuration on the client. However the down side of this method is that you will not be knowing if you are connected to the intended database(server). To a certain extent, man-in-the-middle attack is possible with native network encryption. If an attacker can get into the network and redirect clients to use a malicious database, clients will not be knowing about this although all the communications will be encrypted. However, if the attacker joins the network after the client has finished connecting with the real database, he can't do any damage.
So, it all boils down to where you want to compromise. If you believe the risk of someone impersonating the database in your network is low, you should go ahead with native network encryption. However, if you want maximum security, use TLS/SSL. The downside of TLS/SSL is that it's harder to setup and maintain. You will have to reconfigure all the client connecting to the database, and everytime the server certificate changes you will have to again go to the client for reconfiguration.
Here's a great video explaining both, and the answer is mostly copied from this.
Russ Lowenthal, Director of Product Management for Oracle Security Products explains database security.
Regarding performance comparison between the two method, I don't have anything available at this moment.I will update this answer once I find something. You can see this for a comparison between unencrypted database vs native network encryped database performance.
Hope this will be helpful in some way. Thanks
I've just been doing a bit of wondering and learning, and I wanted to know how this works. I'm pretty sure I understand the concept of public/private key pairs, as i've gotten it to work with ssh, but I was wondering about https sites too. Where does my machine get the key pairs. Does chrome automatically generate a new key pair every session? Is there one hidden on my machine I don't know about?
I could be getting this all wrong, but any help would be great. :)
Browsers only generate key-pairs when the user needs to request a new (typically client) certificate. This is not necessarily related to SSL/TLS, but more of a convenience facility to issue certificates. This has nothing to do with day to day use of HTTPS. (Even if you are using a client-certificate, you only generate the key-pair when that certificate needs to be issued/renewed, typically once a year.)
The keys used for encryption are symmetric keys, negotiated during the handshake, where only the server certificate is required (for authenticated negotiation). You may find more details in this similar question: Can One Public Key be Used to Encrypt and Decrypt Data during the SSL Handshake?
Yes your browser generates only symmetric keys
see http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame2.doc_5.1/ss7aumst18.htm
Im doing a little research about Windows password and I've a little question.
Windows encrypt user passwords and store them on: C:\WINDOWS\system32\config\SAM encrypting them by the NTLM algorithm (plus Syskey)
NTLM is also a network authentication protocols, so I'm messing up with this.
I would like to know if the NTLM encryption is the same of the NTLM network protocol. I mean, in Windows, when you type your user and password, if the system starts a network protocol on the same system (localhost), as it would if they were too different computers (ip).
Or otherwise, if they are two different things with the same name.
It would be great if someone could give me a little explanation about the difference of both methods.
Hope you can understand my question, as I'm not English!
Thanks in advance!
Disclaimer: I work for Microsoft, but not on Windows or any team that developed NTLM. This knowledge comes from external sources and thus may not be accurate.
NTLM is two things: a one-way hash algorithm and an authentication protocol.
The one-way hash function is what the Windows OS uses to store passwords (in the secrets file, as you note.) This is, of course, so that plaintext passwords need not be stored on disk. When you type your password on the login screen, it will be hashed with the NTLM hash algorithm and compared against the existing hash in the secrets file. If they match, you'll be authenticated. If not, you'll be prompted to enter your password again.
The authentication protocol is a challenge/response protocol that authenticates some on-the-wire protocol like CIFS or HTTP. The algorithm utilizes the aforementioned NTLM hash algorithms in order to build the responses to the server's challenges based on the password that the user typed. The protocol specification for the NTLM authentication protocol is available from Microsoft under their Open Specifications license.
To answer your question, when you log in to Windows, it's likely just using the NTLM hash and checking it against the on-disk file, not doing some network call. Of course, if your machine happened to be a domain controller (and, somehow, couldn't do Kerberos) then it may do NTLM authentication over the network to localhost, but that's a pretty contrived example. Of course, if you're hitting a network resource on that local machine (say, CIFS file sharing or hitting a web site) then you'll be using the network authentication protocol, not going directly to the secrets file.
NTLM is not a network protocol. It's an authentication protocol. They are totally separate things.
There's a pretty good discussion of NTLM here. Pay special attention to the fact that NTLM isn't used any longer (it's been replaced by Kerberos and NTLM2, both of which are defined and discussed in the linked article).