Good evening,
I would like to know if when you submit a POST request to Django with your credentials (username/email and password) is normal/save to have that info open in Form Data (dev tools google -> network -> url).
Like that:
It's possible to hide that info or at least encrypt?
Many thanks in advance!
This isn't really a problem. Your request should be protected by HTTPS and no one can see the contents of your form post.
Imagine you could encrypt your password on the client: if someone could see your "plaintext" password they could also see your encrypted one. Since your server decrypts that password, the theoretical attacker would just send the encrypted version instead of your "plaintext" one. The "encrypted" password is now your just another plaintext password, and we are back where we started.
There aren't many good/easy ways to protect an encryption key on the client and maintain usability, especially not in a web app scenario. This is exactly what https/tls is designed to solve, in a general way.
Related
In my Django web-app, I would like the user to authenticate itself with an encrypted email address that would simply be the username. Due to the existing GDPR regulations in my country, I have to encrypt e-mail addresses and by doing it with the help of Python Cryptography and Fernet functions, each string is different after encryption, even if two strings are encrypted with one and the same key. Is it possible to authenticate the user without errors in such a situation? If this is possible, where can I read a little more about it?
EDIT: Maybe I incorrectly specified: Django uses username and password for authentication, if the encrypted email is username, when logging in, the user will enter the email when logging in, i.e. harry#example.com. The database keeps an encrypted version of this email, so when using authenticate(request, username, password), it will look for a user with the username harry#example.com, not the encrypted version. If at this point I would like to decrypt the user's e-mail from the database and compare it with the e-mail that the user entered when logging in, app would probably has to decrypt all e-mails in the database, and then check if and which one is harry#example.com and here, in my opinion, it becomes quite problematic, because I have the impression that it is a not good solution in terms of time and server load. Is there any other way that I will be able to compare the e-mail entered when logging in and the encrypted e-mail in the database?
Here is a good lesson on how to use python cryptography https://www.geeksforgeeks.org/how-to-encrypt-and-decrypt-strings-in-python/
As for GDPR, the user can enter their email but you should encrypt it on the store, then decrypt it when you want to use it. Make sure that your secret is hidden. If someone gets access to your database and your secret, the encryption is as good as if it's not there.
You should not be comparing the encrypted strings, you should decrypt the email and compare it to the email that is currently entered. Comparing hashes should only be done with hashing, not encryption. If you don't want to have access to the user's email, you should consider hashing instead of encrypting.
There's a good read here How do I encrypt and decrypt a string in python?. To know the how-to around what you need. Plus, you described the solution quite well, so take a look at the following packages from the Django community which achieve what you are looking for:
https://github.com/orcasgit/django-fernet-fields/
https://github.com/orcasgit/django-fernet-fields/blob/master/fernet_fields/fields.py#L117 It includes an Encrypted email field
https://github.com/patowc/django-encrypted-field
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.
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.
I'm writing a web app in Django that is interfacing with the Read it Later List API (http://readitlaterlist.com/api/docs/). However, all of the API calls require sending the username and password with each request. In order to do this, it seems that I need to store the user's password in plain text in my database. Am I missing something or is that the only approach possible in this case? Is there some way to store an encrypted password in my database, but yet be able to send a decrypted version of it when making the API call? If not, then are there any best practices that I should be following to safe-guard the user's password?
I'm pretty sure that this can't be the only service requiring sending password in plain-text. I'm interested in knowing how developers deal with these sort of services in general. I'm new to web development, so any help or pointers is appreciated.
do your users have to log into your website to use it? if you also are making use of a password authentication scheme, you could piggy back on top of that. Use the login password for your site as a cipherkey in a symmetric key cipher to encrypt the api password. then you need only store a hash of the users password (to your own site) and an encrypted password for the remote api.
Never save password in plain text. You can encrypt and decrypt the password but the problem is that the key you use to do the encryption and decryption will generally be accessible to anyone who has gained access to your server so it's not secure.
An alternative is to ask them to enter their password and save it in an encrypted cookie, or session variable or something else that will expire when they have logged out of your app. This has the drawback of them having to enter their password every time they user your app.