I have been making websites in Django for 2 years now. A client gave me an ethical-hack report which mentioned that all passwords in my website are clear-text.
I confirmed this by checking the request headers in the 'Network' section in developer console of browsers. I can clearly see my username and password in clear text in the POST queries. This is for all the password fields. Even in django's admin interface login fields.
I am using django's built in UserCreationForm and AuthenticationForm with views from django.contrib.auth, since i thought this is the safest practice.
So should i be worried? Of course Django's developers surely know what they are doing. But is this really safe? Passing cleartext passwords in POST requests? Should i enable django admin in production environment or not?
It is common practice to send the password in plain text. Not only in Django, but in a lot of authentication frameworks. As long as it uses a secure channel (and that channel is not compromised), that should be sufficient.
Normally you communicate nowadays with a server over a encrypted layer like HTTPS. This means that the browser and the server first negotiate encryption, and thus all requests you do are submitted over the encrypted "channel". So the POST request you make to authenticate is encrypted. The browser does not show this, since the request itself contains indeed the password in plain text, but the entire message is encrypted.
Adding extra encryption on top of that would not add much "value". Imagine that you encrypt the password, then that means that if the hacker somehow can intersept and decrypt the package, he/she can send the encrypted password to the server as well.
HTTPS normally aims to prevent a man-in-the-middle attack through certificates.. Sophisticated attacks exists to strip the the SSL layer from a connection, therefore technologies like HSTS [wiki] should be used to prevent protocol downgrades.
Related
I am developing several Web Services that will be accessed by a mobile application. I have several requirements:
Each user will need to sign in with their own User ID and Password (the same User ID and Password they use to sign into the website).
Every Web Service request will need to be authenticated to ensure that the request is coming from the mobile app(s).
Every Web Service request will need to authenticate the user, since there is user-specific fucntionality built in, and access will need to be blocked if the user's account is disabled.
Let's assume that OAuth is not an option.
In order to ensure that Web Service requests are coming only from the mobile app(s), I am planning to use HTTP Basic Authentication in IIS (the mobile app(s) will need to have a User Account setup in Windows Server and the mobile app will need to store the User Name & Password and pass these in the header).
Next is the User Authentication for each Web Service request. Would it be suitable to encrypt the User ID, Password, and some shared secret key (a "pepper", of sort) with AES-256, pass that encrypted string as a parameter with each request (over HTTPS, of course), and then decrypt and parse it on the server to authenticate? This is the existing plan, but something just doesnt seem right about it - like it's not "secure enough".
What else can I do to properly authenticate users for Web Service requests?
I recently went through this problem and asked opinions from a group of senior people about how they solve the problem. Opinions were varied, but one consistent feeling is that your level of security depends on the use case of your application. Are you doing online banking or storing medical records? Then your security needs may be quite high. Social networking? Maybe not so much.
Basic Authentication is generally fine when encrypted over SSL, ColdFusion works well with it. If you use Basic Auth, make sure to encrypt your traffic with 1024-bit keys or better. Don't authenticate every request with username/password - that's unnecessary. Authenticate the first request, set a session token, and rely on the session token for your identification of users.
Set a polling mechanism from the client to the server to keep the session alive - set the session timeout to 30 minutes and the polling frequency at 25 minutes, for example. Otherwise you may need to re-authenticate expired sessions. Again, how you approach this part of the solution depends on your paranoia level, which depends on what kind of data/app you are dealing with.
Cookies, and therefore sessions, should work fine in iOS apps. If you use sessions to verify identity after authentication, make sure your session cookies are memory-only (set at the server level).
Check the SSL implementation of your server against the Qualysis SSL Test:
https://www.ssllabs.com/ssltest/
The report will give you a surprising amount of detail about the strength of your SSL implementation.
Lastly, consider implementing two-factor authentication to combat password theft.
If you ignore the SSL advice and plan on encrypting your password and communicating over an insecure channel, look at the Kerberos protocol for a well-known example of how to authenticate securely:
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
Yes, you can use Basic Authentication but that means the client will need to store the username/password in plain text, and also send them over in plain text. Sending part is sort of fine if it's under HTTPS, but storing username/password in plain text may not be a good idea, unless you're using some secure key store.
Let's assume you have decided that Basic Authentication is the way to go, and you want to make use of the official CF way of supporting that, then you can use CFLOGIN.name & CFLOGIN.password. You may also check out Ask Ben: Manually Enforcing Basic HTTP Authorization In ColdFusion. In the remote cfc side, always validate the username/password, or return some sort of token and asks the client to use that token going forward. The token can be cfid+cftoken if you like, or even roll your own that never expires. If you use cfid+cftoken, and send them over as cookie or in body along with your web service call, I believe you can resume the session if you so choose.
I just started of in Django and want to implement this. But not sure whether my approach is correct or not. Can you validate?
Requirement : My Server will provide a service via an url endpoint. Client will authenticate (with id and password supplied to him via separate channel. So, no signup page available) with his credentials and avail the service. i will do the work asynchronously and reply with status.
My Approach.
. Client will be provided a username and password via separate channel.
. Client will do an https connection.
. Client will encrypt the password with my public Key and will call my URL endpoint with id, password, data.
. i will acknowledge the request and will ping client back when the work is done.
Things i am worried about:
. how to stop snoopers from replacing the data portion and reforwarding the request to me.
. how to stop snoopers from reusing the encrypted password from original request and sending their own request.
Are there any frameworks which will provide this support inbuilt?
OR
This will not occur at all in my current setup?
I know Django provides an authentication module. But not sure about its capabilities.
The framework will help you enable security at an application level. You can use Django to help you ensure that only users that have been properly authenticated will be granted access to restricted pages and provides a number of other security measures out of the box.
Replay attacks will typically be prevented by using sessions, which is well documented by Django.
Based on the description of your implementation, the greatest source of concern would be the statement "client will be provided a username and password via separate channel".
I have a django web app with a RESTful API written using TastyPie. I want to allow my mobile app access to the API that uses username and api_keys, but have struggled to know what the best way to get the api_key back to the mobile client.
I am following the resource code provided here:
How can I login to django using tastypie
My question is if this is a secure method of passing a username and password as data parameters in a POST request. Should I be okay?
Here is an example of the post request:
POST to http://myapp.com/api/user/login with data { 'username' : 'me',
'password' : 'l33t' }.
While data sent over a POST request can be sniffed, that doesn't necessarily mean that you shouldn't be using it to submit user credentials to your RESTful API. So, to answer your question directly:
POSTing a username and password for authentication is not secure. It can be sniffed.
That being said, submitting user credentials in this fashion is something that in my experience is done quite often. A good practice is returning a remember token (or in your case API key) to the user once they have been authenticated. Aside from persisting sessions, the advantage is that if some malicious user gets hold of an API key, it can be reset easily without needing to reset the user's username/password (although it might be a good idea to do so anyway). Of course the downside is that remember tokens/API keys are generally stored in unsafe places like browser cookies/mistakenly in the source of some github repo.
So, is POSTing authentication credentials sniff-proof, no. Can you do it/is it done, yes.
Of course, you can see if HTTPS is an appropriate solution for you in this context if you require more security.
No, sending cleartext credentials is never secure. Anyone sniffing the traffic (including sniffing the traffic and dumping it all into a big logfile) will have the credentials.
When setting Cookiee on the server with properties(httpOnly and secure=true), does that mean it will only be secured during the communication beween server and client, but not after that?
In other words, if the value was originally in plainText -will it also be stored on the client side with plainText (after traveling with https ) -making it unsafe/vulnerable?
1) Do passwords needs to be always encrypt befors sending (even when using https)?
2) Where is httpCookiee (with secure=true) stored? and is this storage access is protected?
You probably don't want store the password.
What you need is store some "user is already authenticated" flag.
After all, you should learn about "digest access authentification". Storing hashed data is always plus.
This answer is too short, mainly bacause here is too much possibilities - and too much open questions.
Handling returning users:
You can manage (server side) an session database. in the cookie you storing only session ID. when the user authenticate itself, you're store into your server side database his status: "logged in". when he log out, you change in the DB status: "logged off".
Handling returning users has nothing with "storing passwords" in any way. You for example can authenticate users by external auth-services, like open-id, twitter, facebook etc., you're only storing his status by some session-ID or similar.
Browsers usually can store user-names/passwords, but this all time should be the user responsibility. When the user want only remeber his passwords, you should not store it in any way.
Why you want complicating your app and security mechanisms with storing encrypted passwords in cookies - what is not a correct solution - from any point of view?
Simple flow:
When an new user comes to your site - you assign him an new session-ID and store the SID into a cookie
when he login (via https) - you're store in your DB = "sessionID" -> "logged in"
when he return after a week, you can (server side) either accept his session-ID from the cookie - and from DB you can get his "logged-in" status, or, you can force login him once again (for example because of expiration)
all of the above is without any risk storing passwords in any way
1) I think so. Because even with secure flag, cookie will be stored in browser cache in plain text
2) It depends on browsers and OS. For Safari in Mac, you can find it in your ~/Library/Cookies/Cookies.plist You can see cookies with Secure flag but in plain text. It may be protected so only owner can see, but it never be good idea to have plain password anywhere in your computer
Once the secure flag is set to true, the cookie will be stored encrypted in the client even after the browser is closed. As you say it is unsafe/vulnerable.
Resp. 1)
Passwords can be encrypted before sending using Javascript, but it doesn't make much sense because https is doing the encryption for you.
Resp. 2)
The cookies are stored in the browser folder. Anybody can open the folder and see the cookies with a text editor.
The browser will handle the passwords for you. Just using a <input type="password"> and using SSL is secure enough.
And, avoid at all costs storing passwords in cookies.
I'm currently working on an application consisting both of a webapplication and client software. The client communicates via webservices, supporting both a SOAP and Protobuffer implementation.
The initial registration is done via the webapplication, which relies on username + password authentication later on.
After finishing the registration process, all features are also available via the client, which will only communicate via HTTPS. For authenticating webservice calls, I'm currently thinking about three possible approaches:
Including the username and password in every message. But is it really a good practice to include the credentials in every request, even though secured by HTTPS?
Providing the username and password in the first webservice request. The client then gets a token which is used for all future requests. (Note: It's not deemed acceptable to force the user to copy a server-generated token to the client application.) Only if the user revokes the token, he needs to send his username and password again for getting a new token. Such token based approaches seem to be quite common, for example Google, AWS and Rackspace are using them a lot. But does it really pay off in this scenario?
Hashing the password on the client sounds like a good solution. However I'd like to salt the encrypted passwords on the server-side. Adding requests only for fetching salts doesn't sound like an optimal solution or is it?
Are there any best practices or tips? I couldn't find too much information exactly for these requirements.
Currently I'd go with 2), but I'm not really convinced yet.
The project is based on Java, Apache CXF, Protobuffers and Shiro, but shouldn't have too much of an impact for the general question...
If you're only concerned by authentification and neither by confidentiality nor integrity, you can handle it by securing:
HTTP transport level, using HTTP BasicAuth (user+password on each message) + eventually HTTPS for confidentiality, however as you noticed (solution 1) it it is kind of old school and keeping user/password in local cache is not a big deal but cannot be advised.
Message level (the soap message) using Security Token for instance but I do not know Protobuffer
Application level (solution 2 and 3), that is the way Google, Amazon, Ebay and others are working. You will not ask the user to copy/paste his token, you will generate one from user/password
I would securing the application level using a token, since getting a salt from the server is almost like getting a token and does not add more security (a secured salt should be known from only you, and if channel is protected it mean getting the token from given password and username is secured as well).
A better but more complex solution would be usage of SSL certificates, available both in browser and client software.