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.
Related
I am building up a small iot-like system, where mqtt devices(clients) are sending and receiving security-related critical information or commands.
I have got to know that TLS connection can be built optionally without client authentication thru PK certificate on the client side.
Normally, mqtt client devices don't have enough resources to support PKI, where at first it has to store a certificate and from time to time, to update it with newly issued ones when validity has passed or when the original certificate has been revoked.
That was, I think, why many of mqtt brokers have an option to configure on/off the client authentication during TLS handshake.
However, my concern is if there would be any security issue from passing the client authentication step, like, for example, a chance that some other malicious devices impersonating one of my devices can connect to the broker could obtain those critical information and commands.
My question is what best options and practices I can take to minimize that kind of risk considering the constraint resource of devices.
Missing client authentication means that everybody including an attacker can claim to be a valid client. There can be use cases like public services where this is not a problem and there are other use cases where the server wants to restrict access to specific known clients only.
There is no definitive answer to this question, it will always depend on the following factors, and only you as the designer can answer them:
What is the threat model you are working with? E.g. Who are you trying to keep out of the system and why, what are the consequences of somebody connecting a rouge client?
How much are you prepared to spend? If you intend to deploy client certificate or even a unique username/password for each device, how will it be protected? Does the hardware you intend to use support a secure enclave/hardware secret store? Meaning how hard would it be for an attacker to extract the client username/password or secret key from the device?
What other security measures do you have in place? Do you have Access Control Lists to protect which topics a client can publish/subscribe to? Do you have monitoring in place to detect malicious actions from clients so they can be disconnected and banned?
We are currently working on a data-backup kinda project. We ship our own hardware to industrial customers. This hardware will then read out all related data the customer wants to backup and sends them to a cloud server using MQTT (Node.js Client and Mosca MQTT Broker).
Now my questions are:
Is there a free TLS certificate that i can use for my MQTT connection? The only ones that i found require a domain name.
To incease security, we are using JWT. We don't have any database though. The Token will be passed as an MQTT-Password argument. Is there a better alternative?
Is a self-signed TLS certificate bad practice even if the private cert
is not publicly available? It will only be shipped embedded into our
hardware and to our verified customers.
Of course it is bad practice (very bad practice). Get a certificate from a proper CA authority. Unless you want your company to be sued into the stone-age for a security breach.
Is there a free TLS certificate that i can use for my MQTT connection? The only ones that i found require a domain name.
The certificate "certifies" that the information is provided by a specific entity, where the entity is defined as "a domain name".
Asking for a TLS certificate which doesn't back to a domain name is like asking for a certified check drawn on a company that doesn't have a name.
To incease security, we are using JWT. We don't have any database though. The Token will be passed as an MQTT-Password argument. Is there a better alternative?
Yes, there is a better alternative. Have some sort of database (it can be a file system, it doesn't need to be a full-fledged SQL database) hold and manage the created tokens. Without a database to validate the tokens against the current expected values, any kind of token based security (JWT or otherwise) will be useless, as you can't determine if the token is currently valid.
Credential reuse (the replay of should-be-expired credentials) is a major security hole. All one needs to do is obtain the token, and then all future communications are accepted with the same credentials. This is closed by holding the tokens in a database, and expiring the tokens after some time by removing the tokens from the database. This means that any possible breach is limited to a shorter time span.
Without any kind of database, I can only guess that you might be permitting any access with an existing token, meaning that all your tokens are effectively valid forever, as they will be accepted if they exist. You need to possibly modify, and certainly validate, that expired tokens don't grant access to the controlled operations.
Your clients will connect to your MQTT broker, for this to be secure you will need a certificate which is tied to the address (domain name) the broker is running on. Clients need to know that the server they are talking to is authentic, the information needed for this is inside the certificate. If you're looking for a free certificate you could look at Let's encrypt
As for the JWT token, why are you looking for a better alternative? What issues doe you see?
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 ask this because I work on an application where the X-AUTH-TOKEN can be copied from one request to another and impersonate another person. This makes me nervous, but I'm told since we're going to use HTTPS we don't have to worry about anything.
So, my question is: Is it good enough trust SSL to protect against stealing headers used for auth/sessions?
Thanks,
Using HTTPS encryption will indeed prevent someone from stealing your authentication token if they can intercept the traffic. It won't necessarily prevent a man-in-the-middle attack though unless the client enables peer certificate checking.
This question from the security stackexchange describes how to implement MITM attacks against SSL. If I can convince a client running HTTPS to connect to my server, and they accept my certificate then I can steal your authentication token and re-use it. Peer certificate validation is sometimes a bit of a pain to setup but it can give you a higher chance of whomever you are connecting to are who they say that are.
"Good enough" is a relative definition and depends on your level of paranoia. Personally I would be happy that my connection is secure enough with HTTPS and peer certificate validation turned on.
Presumably also your authentication token times out so the attack window would be time limited. For example the OpenStack authentication token is by default valid for 24 hours before it expires and then you are required to obtain a new one.
The HTTPS standard implements HTTP entirely on top of SSL/TLS. Because of this, practically everything except for the DNS query is encrypted. Since headers are part of the request and response, and only sent after the secure-channel has been created, they are precisely as secure as the implementation of HTTPS on the given server.
HTTPS is an end-to-end encryption of the entire HTTP session, including the headers, so on the face of it, you should be safe from eavesdropping.
However, that is only part of the story: depending on how the clients are actually connecting (is this a website or an API service?), it may still be possible to trick them into sending the data to the wrong place, for instance:
Presenting a "man in the middle" site with an invalid SSL certificate (since it won't be from a trusted authority, or won't be for the right domain) but convincing users to by-pass this check. Modern browsers make a big fuss about this kind of thing, but libraries for connecting to APIs might not.
Presenting a different site / service end-point at a slightly different URL, with a valid SSL certificate, harvesting authentication tokens, and using them to connect to the real service.
Harvesting the token inside the client application, before it is sent over HTTPS.
No one approach to security is ever sufficient to prevent all attacks. The main consideration should be the trade-off between how complex additional measures would be to implement vs the damage that could be done if an attacker exploited you not doing them.
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