We are currently implementing several web application that requires the user to create a user login that will be authenticated through LDAP calls. The LDAP server and user accounts will be shared by all the applications and the user's credentials will be the same across all applications.
My question is where does the hashing take place in a standard LDAP scenario, on the client side or does the LDAP server take care of it. It was my understanding that the LDAP server takes in a user password, at the time of creation, and hashes it and stores it. (By the by we plan on using salted SHA512 hashing and SSL connections between the client > webserver > LDAp server)
It was my understanding that the hashing operation takes place centrally on the LDAP server, relieving the client of the trouble and avoiding any breakage on the client end to affect other apps.
Modern, professional-quality servers use storage schemes for password attributes (usually userPassword and authPassword) that involve executing the hash on the server. Servers usually append or prepend a unique value (called a salt) to a password, then execute the hash function. The "salt" minimizes the effectiveness of dictionary attacks, that is, dictionaries are more difficult to create for salted, hashed passwords.
SSL (a secure connection) should be used, or a non-secure connection should be promoted using the StartTLS extended request. An encrypted connection should be used so that passwords can be transmitted in the clear with BIND requests. Passwords that are transmitted in the clear over a secure connection can be checked for history and quality by the servers' password policy enforcement mechanisms. For servers that enforce password history and quality checks, passwords should not be transmitted pre-encoded. Therefore, it is not so much the "trouble" to the LDAP client as it is the fact that the server can enforcement organization-wide and agreed-to password quality and history checks in a central location.
see also
LDAP: StartTLS request
LDAP: Programming Practices
Related
I'm running Nessus on one of my websites and it returns "Web Server Transmits Cleartext Credentials" vulnerability. It is a low level vulnerability, but I want to understand it.
My website encrypts the password text box and that is sent to a database procedure to compare to what encrypted password I have for that user in my database. So even if it was cleartext the encrypted password is being sent across. Does this mean that this vulnerability doesn't apply to my website or am I still allowing the password to be exposed?
Thank you
I believe there are multiple facets to your potential security issue. This would fail most audits if there is any sensitivity regarding the web service.
This vulnerability occurs because you are not using HTTPS, while handling passwords. (a password field in a form). So yes you are vulnerable to this technically. A Man In The Middle attack could see what is being transmitted and re-use that "encrypted" value. They could also modify the data to cause other actions to occur, depending upon design flaws. You have at least one concern that you have not mitigated here. HTTPS is the best solution to prevent MITM.
Beyond the first point - You seem to be indicating that you know the password value placed into the password field/box by a user is being encrypted before transmission to the server. If the value is being encrypted by using javascript inside the browser, then you are likely not properly securing the password. Client-side javascript is a poor method to implement security controls like this. (especially if there is no MITM-prevention) But if someone is simply pasting an "encrypted" value from somewhere outside the web browser into the browser form and sending it to the server, then the nature of the encryption is a key point. It should be using well known modern encyption protocols such as AES. But this is meaningless if anyone can capture the value via MITM attack and re-use it.
Strongly urge the adoption of TLS security via HTTPS configuration for the web service.
I've been reading and trying to comprehend the differences in browser side security. From what I gather, SSL is used to keep people from sniffing the traffic you send to the server. This allows you to send a password to a server in clear text...right? As long as you are in an SSL encrypted session you don't have to worry about hashing the password first or anything weird, just send it straight to the server along with the username. After the user authenticates you send them back a JWT and then all future requests to the server should include this JWT assuming they are trying to access a secured area. This allows the server to not even have to check the password, all the server does is verify the signature and that's all the server cares about. As long as the signature is verified you give the client whatever info they are requesting. Have I missed something?
You are correct. "This allows the server not to even have to check the password." Why would you have to check a password on each request?
A JWT is a means of verifying authentication. It is generated upon a successful authentication request and hence forth passed with each request to let the server know this user is authenticated.
It can be used to store arbitrary values such as user_id or api_key but they are not very secure so don't store any valuable information here.
Be wary though, if a plain JWT is intercepted by a third party, it can assume this user's session and possible data.
SSL is a lower level form of security, encrypting every request from and to the server to prevent interception and retains integrity.
SSL is achieved by (purchasing) an SSL certificate and installing it on your server. Basically an SSL certificate is a small data file that binds a cryptographic key to an 'organisation'. Once installed succesfully, HTTPS requests (on port 443 by default) are possible.
I am asking myself. What is the best way to send personal information from your iOS device to the server.
At this moment I encrypt the password in the app ( sha1 salt password pepper ) then I send post data using from iOS to the server.
What is the best way to protect the user and secure for any MITM attacks. Is my way secure enough?
UPDATE:
I added the SSL certificate. To make sure the user only has to login once I store a key generated when the user registered. I fetch them when the user logins for the first time. In oombination with the username and user id. Is this a good way? Only jailbroken users can read it and have risk.
Hashing the password on the client side will help prevent the password itself from being detected in eavesdropping, but it really doesn't provide any security on its own, as the credential then becomes the hashed version of the password, not the original password itself. An eavesdropper could just grab the hashed version, and then send the hash themselves.
By far the easiest solution is to simply use SSL/TLS. Since you mentioned 'post', that means you're probably using HTTP. Instead, you could just connect via HTTPS and post the data, exactly the same as you're doing already. Long as the certificate is checked for validity (I believe the iOS framework already does such by default), then the connection should be largely secured.
That should be good enough for most situations. There are some more complicated and involved techniques you can use to harden further, but SSL/TLS does a massive amount on its own.
Can some please describe to me the SMTP authentication in broad terms keeping in mind the below.
When someone asks 'what authentication are you using?'
What are they referring to? Which variant of SMTP protocol like ESMTP and POP-before-SMTP?
How many variants are there? and within those protocols I am reading about things like Auth Mechanisms (Auth login, Auth plain, CRAM-MD 5) ?
Can someone shed some light at a broad level here?
There are many layers and many aspects here. There are multiple relevant ESMTP extensions and multiple authentication schemes.
How you connect affects which authentication scheme makes sense. Generally speaking, if you have an encrypted connection, plaintext passwords are unproblematic, because the connection-level encryption takes care of preventing eavesdropping.
If you don't have an encrypted connection, ideally you will not want to transfer the password in any form at all. There are various authentication schemes involving challenge-response mechanisms or session password exchange in order to authenticate securely even over an unencrypted channel.
POP-before-SMTP was at one time popular because there were no adequate standards for authenticating SMTP. These days, it should be considered merely historical, although there are probably still some sites using this mechanism. The idea is to defer authentication to the POP protocol, which requires user authentication anyway; then when the user has authenticated over POP, the SMTP port is also permitted from the same IP address for a limited time. Obviously, if the user doesn't have or want to use POP, this is cumbersome, and some users are on NAT so that the IP address seen by the remote server is not uniquely theirs, but once upon a time, this arrangement fit quite naturally into how people connected to the Internet via dial-up PPP using their own ISP's POP and SMTP services only.
These days, for new systems, the default should be to set up a separate encrypted and authenticated Mail Submission Agent port 587 in accordance with RFC 6409. Some systems run a traditional SMTP server on port 465 over an encrypted channel, but this should be considered a legacy arrangement.
See further http://en.wikipedia.org/wiki/SMTP_Authentication and http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol both of which I relied on heavily for this write-up.
This is probably a dumb question but can I do away safely with just basic HTTP auth or do I still benefit from digest auth even if the server is already on SSL?
The only advantage you would gain by using HTTP Digest authentication over SSL/TLS is to prevent the disclosure of the user password to the server itself, if your sever is capable of being configured with passwords in "HA1 format" directly (i.e. if it doesn't need to know the password itself, but where the user password can be configured with MD5(username:realm:password), without requiring the password in clear, see Apache Httpd for example).
In practice, this isn't really a big advantage. There are better alternatives if protecting the password itself from the server is required (in particular because MD5 isn't considered good enough anyway nowadays).
The other features of HTTP Digest authentication (over form/HTTP Basic) are already provided by the SSL/TLS layer.
Across ssl basic auth is secure enough for most needs.