How secure would it be to have a external machine create hashes for passwords. So you would have simple webservers and one heavy machine that is being used by the webservers to create strong Bcrypt hashes. This system doesn't need to have the user's account name just the password so that would not be a security issue.
It is less secure as you have an additional machine and a communication channel to secure. You gain nothing by hashing passwords remotely.
Related
Hey :) I’m learning about Kerberos. I first read about the MIT Kerberos and then about the uses in Microsoft. I found some difference. I just want to be sure. Is it right that in the original MIT Kerberos a hash of the password never send from the client to the server, but in Microsoft Kerberos it happened?
Huh?
Kerberos is Kerberos. It's a well defined specification and all the different implementations are more or less implemented the same. The Windows implementation certainly has it's share of quirks, but it doesn't in any way send the password hash to the server.
Kerberos uses a key agreement process to exchange messages. Both the client and KDC know the users "long term credential" which is their password hashed using a specific key derivation function. When the client wants to send a message to the KDC, it encrypts it using the long term credential. The KDC knows that credential so it can decrypt it. The response is encrypted in the same way.
Neither party sends the password or its hash to the other in general use.
There are two separate but specific scenarios where this doesn't apply however.
When using a certificate to logon via PKINIT, Windows will include the long term credential in the user PAC of the ticket (so the workstation can decrypt it), encrypted to the Diffie-Hellman derived secret.
The other scenario is when doing FIDO logon, the long term credential is included in an authorization data element.
Both of these scenarios exist to allow clients to support legacy protocols that only understand password authentication.
MQTT or REST from an ESP8266 without TLS is risky. Passing unencrypted credentials and tokens around doesn't strike me as being terribly secure. But TLS communications on the ESP8266 requires a large chunk of memory, and to avoid man-in-the-middle attacks you really have to verify the server certificate, generally done using an SHA1 fingerprint. But the SHA1 fingerprint will change as the server certificate changes, so hard-coding it isn't an option. Asking a user to go and find their SHA1 certificate fingerprint using their browser dev tools and insert it into a web config portal is pretty much a no-no too.
Has anyone come up with a workable solution to this conundrum? One which delivers excellent security with greatest genericity, soft settings and least user-involvement? What's the best way of effortlessly achieving a high level of security for outside-firewall communications on an ESP8266?
The ESP8266 Arduino project introduced verifying with root CA certificates which is heaps better than using fingerprints. They have an example of it for GitHub here: https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WiFi/examples/HTTPSRequestCACert
I'm trying to apply security best practices to an AWS RDS postgresql instance, but Amazon seems to have gone out of its way to prevent some fairly common and routine features around authentication. I don't seem to be able to authenticate against any external source, which sucks, since now I have to maintain db users completely separately from normal user management. But it seems that, despite the fact that I can use SSL to connect, none of the functionality that might actually validate a client's cert against the server's CA is accessible in RDS. Is this true? It seems like the easiest thing in the world to have amazon sign certs with it CA and then validate those certs against that CA when connections are established, yet I cannot find any mention of how to do it in the documentation or out on the web. Am I really confined ONLY to password authentication of db-internal users? This is almost hard to believe, but after days of research, is the only conclusion I have been able to support.
Does kerberos encrypt only the authentication process or all client communications?
I was under the impression it was like a VPN for the LAN.
So that all LAN communications are encrypted. Just like all internet communications are encrypted with a VPN.
Regards
Aubrey
Kerberos is quite capable of encrypting traffic between client and server, but depending on exactly how kerberos is used in the application, it may or may not be using the kerberos session keys to encrypt the traffic.
The kerberos protocol provides the means to exchange a session key that can be used to encrypt message traffic after the initial authentication exchange. Encrypted message exchange is generally the default for protocols that actually use GSSAPI. See gss_wrap documentation
GSSAPI is a generalized API for doing secure network applications. Kerberos is the mostly commonly used driver underneath GSSAPI.
If the application does not use GSSAPI, or the native kerberos messaging libraries, then it is likely using TLS to encrypt the traffic or the traffic is not encrypted.
Kerberos message encryption was designed to support relatively long lived tcp based client/server applications ( think telnet or ssh ). The API does not always map well to the way current applications are architected. Kerberos support is often bolted on well after the application is under construction
and is only used for authentication.
Kerberos is an distributed service that is generally used for secure authentication only. It does neither ensure that a user has the required permissions to access a resource (that would be Authorization) however it may be used to encrypt arbitrary data. As per RFC 3961 "Encryption and Checksum Specifications" which extends and correct aspects of RFC 1510 the Kerberos protocol provides confidentiality and integrity services.
While Kerberos can be used to encrypt information passed between authenticated peers in many cases it only performs the authentication step. Thus, you will find that Kerberos is used as component in a secure environment to ensure a secure authentication with other components and protocols handling the authorization and the secure transport.
In the end, it heavily depends on your usa-case to determine if the tradeoffs between using Kerberos or something else as a transport protocol make sense for you.
While the Kerberos protocol can be used to provide encryption services on most platforms, microsoft provides no mechanism to do this directory. Instead GSSAPI may be used to call these services.
For example, Active Directory uses Kerberos for message integrity.
Similarly, you could use e.g. TLS or IPsec to encrypt your data on the wire and combine it with Kerberos for authentication. But again, this is another protocol performing the actual transport encryption and just using Kerberos as an authentication component.
Currently I am using Net::LDAP::Server to setup my server but it is not secure enough.
Is there any module or method so that I can setup a LDAP server over TLS or other secure connection?
I just found many information about how to connect to a secure ldap server, but cant found how to setup a secure ldap server.
Can anyone give some advices?
How does an LDAPS connection work
LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured SSL ("Secure Socket Layer") connection to port 636 (by default).
Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port.
Using LDAPS can potentially solve the vulnerabilities described above, but you should be aware that simply "using" SSL is not a magic bullet that automatically makes your system "secure".
First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake. This is done in two ways:
check that the certificate is signed (trusted) by someone that you trust, and that the certificate hasn't been revoked. For instance, the server's certificate may have been signed by Verisign (www.verisign.com), and you decide that you want to trust Verisign to sign legitimate certificates.
check that the least-significant cn RDN in the server's certificate's DN is the fully-qualified hostname of the hostname that you connected to when creating the LDAPS object. For example if the server is , then the RDN to check is cn=ldap.example.com.
You can do this by using the cafile and capath options when creating a Net::LDAPS object, and by setting the verify option to 'require'.
To prevent hackers 'sniffing' passwords and other information on your connection, you also have to make sure the encryption algorithm used by the SSL connection is good enough. This is also something that gets decided by the SSL handshake - if the client and server cannot agree on an acceptable algorithm the connection is not made.
Net::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for ones considered to use "low" strength encryption, and those using export strength encryption. You can override this when you create the Net::LDAPS object using the 'ciphers' option.
Once you've made the secure connection, you should also check that the encryption algorithm that is actually being used is one that you find acceptable. Broken servers have been observed in the field which 'fail over' and give you an unencrypted connection, so you ought to check for that.
How does LDAP and TLS work
SSL is a good solution to many network security problems, but it is not a standard. The IETF corrected some defects in the SSL mechanism and published a standard called RFC 2246 which describes TLS ("Transport Layer Security"), which is simply a cleaned up and standardized version of SSL.
You can only use TLS with an LDAPv3 server. That is because the standard (RFC 2830) for LDAP and TLS requires that the normal LDAP connection (ie., on port 389) can be switched on demand from plain text into a TLS connection. The switching mechanism uses a special extended LDAP operation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3 connection.
So the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using Net::LDAP::new(), and then you perform the switch using Net::LDAP::start_tls(). The start_tls() method takes pretty much the same arguments as Net::LDAPS::new(), so check above for details.
Well, perhaps LDAPS is not an RFC but to say it is not a standard or secure is certainly a stretch.
LDAPS is supported by ALL LDAP Server Vendors.
LDAPS is at least as secure as HTTPS.
As with ALL SSL (or TLS) the security weak points are how the certificates are handled.
Certainly LDAPS is more supported by LDAP server vendors and clients than is TLS. Active Directory as one example, does not support TLS. Querying the rootDSE for the supportedExtention 1.3.6.1.4.1.1466.20037 will (should) show if TLS is supported on any particular LDAP server.
We have some examples at:
http://ldapwiki.willeke.com/wiki/Perl%20LDAP%20Samples.