By seeing this answer I learned that Google blocks certain apps to connect, due to "lack of application of modern security standards" in those apps, and I can make Google allow my account to connect from such apps - I must do that explicitly.
This was due to an issue in Django mailing:
send_mail(
u"Message",
render_to_string('template.txt', {'data': data}),
settings.EMAIL_HOST_USER,
[dest['address'] for dest in settings.FORM_DESTINATIONS],
html_message=render_to_string('template.html', {'data': data}),
)
And my EMAIL_ settings involving a #gmail.com account (neither SSL/465 or TLS/587 worked).
Does this mean Django 1.7 has an insecure mailing mechanism? What does "secure" mean in this context and what mailing standards is Django not applying?
Edit Even when I provided context for this question (a pointed answer and related links/docs) perhaps some readers may not find where does Google talks about "secure"/"insecure" applications. By entering here using your google account credentials there's an option telling about "less secure apps" which lead to this page, which has a "More Info" link, pointing Here (this link does not need authentication).
Sending email via SMTP with Django requires you to store you password in plain text on your server. Apparently, Google considers storing the password in plain text a security risk and wants you to use either OAuth 2.0 or two factor authentication with application specific passwords. See
http://googleonlinesecurity.blogspot.de/2014/04/new-security-measures-will-affect-older.html
It is up to you to decide whether you consider storing the email password in plain text on a server a security risk. Keep in mind that you usually store your database password in plain text too, so when an attacker is able to read your application settings, it is pretty much game over anyway.
I would suggest enabling two factor authentication and using an application specific password, especially if you use that Google account for more than just sending mail from your server.
Related
I have developed a small application for submitting some data to database server(Oracle 11g). When we are reviewing security of this small application, we observed as follows:
1. We have deployed django with https and all secure configurations like Secure Cookie and Secure Session, No Cache, etc.
2. Using BURP tool for this sample review
3. We have created two different user in this system say Normal User and Admin User
4. Opened 2 browsers(Mozilla and IE 11), On mozilla we login with Admin user and captured session id using burp tool.
5. On second browser we login with Normal user and replaced session id Normal User with Admin User.
6. whoila......On second browser, I got Admin user access by just changing the session id
I have used default session backend for this application.
I would like to know whether this is flaw in django and how to resolve this issue..
Thanks in advance
This is an inherent risk of using session-based identification. It's called session hijacking, and if you search for that term you will find lots of information.
Mitigations generally have one of two goals: making it harder to steal the token, or making the damage less severe if it is stolen. In the former camp are techniques like using HTTPS and SESSION_COOKIE_HTTPONLY. In the latter are things like limiting the length of a valid session (SESSION_COOKIE_AGE). In the end, though, it's difficult or impossible to stop someone from impersonating another user if they get their token, since that's the very thing that establishes identity.
I'm thinking about migrating one of my django application to meteor. But there is one question I'm trying to answer before doing this: How does Meteor encrypt a password? (with the account-password package?)
In my case, I used the default django password encryption:
Django provides a flexible password storage system and uses PBKDF2 by default.
The password attribute of a User object is a string in this format:
<algorithm>$<iterations>$<salt>$<hash>
So my passwords are stored like this:
pbkdf2_sha256$12000$Z0rof3EQy1p2$wezcf334ytyBm12CPcdlNZLrkWYkaQklk4wHt5jxgWE=
Is it impossible to make Meteor adopt the same scheme so as my current users can continue to use my application without resetting their password?
accounts-password uses SRP to authenticate users. This was mentioned in the blog post for meteor 0.5:
Support for the Secure Remote Password protocol. Developed at Stanford, SRP lets a user securely log in to a server without ever sending that server their unencrypted password. The kind of high-profile security breaches at LinkedIn and Pandora earlier this year are impossible with SRP. Instead of asking every application developer to safely store passwords, we've baked the very best technology right into Meteor Accounts.
It's also discussed a little bit in this recent video. Side note - it's interesting that they are considering adding bcrypt in the future.
So for now, the good news is that meteor does not store password-equivalent information in the database. The bad news is that your users will need to reset their passwords if you choose to migrate your framework.
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.
I have requirement like, each user of the site
will be mailing any other user and I have rules for that communication
(let them aside for now). So user1 will be picking an email id like:
mypickeduser1n...#sitedomain.com and will be sending an email to
user2, whose email id will be like:
mypickeduser2n...#sitedomain.com. Like that any number of users will
be sending emails to any numbers of users. And any outsider should be
able to send an email to mypickeduser2n...#sitedomain.com. My question
is,So in this context, do I need to build my own smtp(setup mailing)
servers. I am totally a newbie in the smtp arena. Can I achieve the
email communication between the users without "mailing server"
configurations?
Can this be achievable?
You need a mail server. Even if local email is just directly deposited into a mail directory or database somewhere, something has to be responsible for accepting email from the outside world. I recommend postfix - it's powerful but easy to set up, and the config files don't look like Klingon.
If you want users to be able to create e-mail accounts in Django, you need Django, your MTA and your IMAP/POP server to use the same user account database.
I've successfully used the following setup:
PostgreSQL as the user database
Postfix as the MTA
Dovecot as the IMAP server
a custom Django app as the user account management front-end
virtual mail user accounts (not using Unix accounts)
I've only used the Django admin interface to let administrators manage the mail accounts, but a management UI for users is trivial to implement as well.
Some tips and sources of information for such a setup:
Design your database schema carefully. I based mine on howtos mentioned below with modifications for easier Django integration.
Take care that all components use the same encryption for user passwords.
two howtos (first, second) describing how Dovecot and Postfix can authenticate users using PAM and PostgreSQL as backend
a howto in German for Dovecot/Postfix/PostgreSQL
a howto for gluing together virtual user/domain support for Debian, Postfix 2 with SMTP AUTH, SASL2 with libpam-pgsql for Postfix, PostgreSQL and Dovecot
the Postfix PostgreSQL howto
You might also want to check out the Virtual Mail Manager command line tool for managing domains, accounts and aliases with a Dovecot/Postfix/PostgreSQL setup.
There are a few django apps out there to handle messaging between users, but the only one that seems to be active is:
django-messages
This gives you all the functionality you asked for, except for outsiders being able to send mail in to users.
This is a much harder problem and will certainly require a mail server and much custom code on your part.