I know that passwords should not be stored for decryption, but what if it's required? So I am wondering how do mail clients (Outlook, Thunderbird, etc.) encrypt\store passwords for sending and checking mail (I do believe they do it safely enough). In general, what are the good practices for storing user's mail password to save him time entering it every time he wants to send the email?
My passwords are only for email accounts.
If memory serves, Outlook at least used to use Windows Protected Storage. I haven't checked, but I'd guess that the current version(s) use CryptProtectData and company.
To answer a sort-of-implied question: I haven't looked as carefully at CryptProtectData, but Windows Protected Storage was not really very secure as a general rule (i.e., tools were/are available that would typically show its contents in a matter of minutes, if not seconds).
Related
I recently received an email through Gmail which I happened to forward on to another account of mine luckily...
When trying to find the original email, I searched and searched, and couldn't understand why it wasn't there?!
Turns out Gmail recently introduced Confidential emails, I'm sure this is useful for some people, but this is an absolute nightmare for me. Anything with importance enough to send confidentially, is critically important and must be kept.
For those of you who also have no idea what this is like I didn't; you can set a time limit for the email, or withdraw it at any time, and gmail will unassign the recipient from being able to read it,although it still persists on the server
Does anyone know how I can set an automatic rule in Gmail to specifically make a copy of only emails with this new "confidential" tag? Or at least emails that are time limited / can be withdrawn?
I know there are rules to copy all incoming mail, this is not what I want as it would fill my inbox twice as fast (already many GB)
I'm currently running a SAAS application and mails are being sent from our application using Mailjet.
Some of the larger customers have been asking to allow the emails to be sent from their domain (e.g. info#largehotel.com) instead of our system (notifications#saasapp.com).
Are there any initial pointers I will need to look at? I'm guessing they will need to add our SPF records to their SPF records too and that they will need add a DKIM key that we generate for them to add to their records too? Then do some validation on them on the DNS level and mark them as validated?
I have some understanding to have customers run their own domain against our SAAS domain but a bit lost on the sending from their email domain requirement.
First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)
You have two(ish) options
Send email through your client’s mail servers (instead of mailjet)
Verify the client’s domain on your Mailjet (or similar email) service
option 1
With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:
Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.
If you’re sending out as a fairly common email address (eg info#your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.
You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)
Option 2
For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.
You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.
That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.
You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide
So for this, you’ll need your client to setup 3 DNS records.
If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it 😜
Conclusion
How important is the tracking? If you can’t lose that you need to go with option 2.
How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.
Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.
Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate 😀
your web app
This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.
option 2b
just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin#yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)
you can ask your client to generate programmatic(app key/password) user for email need to use for example info#largehotel.com and some other info like (host:gmail, protocol: smtp,...) all basic info needed then in your saas retrieve all this info to create object with client info that you stored before to send email for the target (from developer prospective non network engineering )
The SPF is the most important think to do. In most cases you have to be very careful about the IP reputation, but since you are using Mailjet it's up to them to manage this part.
Be attentive to the overall quality of the email, text/image ratio... Also offers a text body version of the content and dont forget the unsubscribe link. Since you already send emails with your service, I guess it's points are already correct.
Encrypted email - sounds like a great thing, right? Problem already solved, right? Well... I don't think so and I'm hoping I'm wrong!
To understand what I'm asking, please understand what I'm NOT asking: I am not asking how I encrypt and sign messages sent over public networks. This is a bit different.
I want to set up a mail server where email clients can both read and post and their messages to the mail server encrypted in both directions, preferably using standard clients available at internet cafes, etc, without requirement for specialized software or encrypted port-forwarding a-la SSH.
The key here is that there is a trusted mail server which can deliver email to a community using a local-delivery-agent. One can then send email to and receive from anyone and everyone who also uses that same system without concern for the security of their communications. There's no need to encrypt every message using the public key of every recipient - what pain THAT would be! - and instead all we're talking about here is a bidirectional communication that's encrypted from clients to this system.
Of course, public messages come in unencrypted via the usual port 25 process to all participants of the email server. They may or may not be encrypted as they were - we're not worried about them. Email Clients connect from anywhere and the responding code on the server system encrypts those messages for reading, even though they were sent through the public network in plain text already... This much I can already get fairly easily with encrypting IMAP servers like Dovecot.
What I want to add to this is that connected email clients can send email, encrypted, back to the system of which they are a client wherein that system forwards externally unencrypted, wherever it needs to go. If it's a local mailbox, the message is delivered via a local delivery agent. No keys involved there. The advantage of this design is that there's NO exposure of the email to external, untrusted systems or networks, and if the delivery is local, it's effectively protected end-to-end WITHOUT having a point-to-point hassle of encrypting individual messages in the more typical use.
This would be "god send" because as it is now, it's impossible to send secured mail through clients on the public internet to groups of people within an internal network.
I guess another way to phrase what I’m asking for is: Has someone created a package that gives us the other half of the encryption that IMAP (and POP?) servers already do – that distant clients on untrusted networks can hand-off out-bound unencrypted email through an encrypted link to the server on the other end?
ANOTHER ALTERNATIVE occurred to me: Encrypting SMTP / ESMTP servers that talk mail server to mail server in an encrypted form. (Similarly, clients should be able to hand off unencrypted email through an encrypted link, much as https works.) Anybody know of such a package? This is not quite as good, but an important part of email architecture...
If this doesn’t exist today, it should!
Thanks for your thoughts, pointers, etc.
Most existing email clients support message submission (either using SMTP or MSA) via TLS/SSL. I just checked in Outlook and Opera and both support it.
And I know for a fact that Courier's email suite supports TLS/SSL for both SMTP and MSA (and IMAP), so it's not an obscure setup; just a little uncommon. And it supports requiring TLS/SSL for any or all protocols.
Here is an example client SSL config screen.
Outlook Express:
I have a program that, for the most part, operates in the background. Let's say it DoesWork(). Once a week, I want it to notify the user on some of the work it has completed over the past few days. It will be a basic status report, listing some files that have been downloaded.
Initially, I wanted to sent this status update via email, so I looked into that but there are a lot of problems. I need an SMTP server so I looked at GMail. It's okay but has a daily limit of 500 emails, so this wouldn't be suitable for release. Also, there would be issues with the same email account password being given out in each copy of the program, which as I understand it, is a risk even if the password is stored using encryption.
Then I thought maybe I could use the user's own email account to send email to his/her self. This has a couple of complications too: the user would need to specify all of the smtp information for his/her email account, which is too complicated for the target user. Also, I don't want to have to have people entering their email account password into my program just to send emails. I don't think that's a good habit to promote.
Is there any way I could do this via email? Email was my first choice because it's a system of notification that users will already be checking. It's fairly non-intrusive.
Is it necessary to setup my own smtp server? If so, how can I do that?
If email is a no-go, I was also thinking about just generating a local HTML file with the relevent information, and then having a notification popup from the program once a week to inform the user that a new update report is ready. I think this is totally doable, it's just overly instrusive and not my first choice. I want to piggyback on a system that the user is already using.
Thanks!
-greg
An alternative is to have the program generate an RSS feed and direct the user how to subscribe to it. Also, once a new update is generated, show the update toast for about a minute, then hide it automatically and change your systray icon to something different. In about a day change it back to the original icon. Also, give the user a setting to turn the toast off permanently.
Relying on email is not a good idea, as you would have to collect the user emails and deal with the privacy issues for that, you would be effectively DOSing any third party SMTP server or would have to invest in the infrastructure for your own.
If I've understood it correctly, the user is running this program on his pc, in the background.
The perfect way to notify something would be, IMHO, giving the program is minimized to the traybar, a small popup that clicked, would open a window with a weekly report.
Hope this helps.
If you do get them to specify their own smtp server, make sure you put a "Send Test Email" button on there so they can test it. I know from experience that users always enter the wrong details when specifying a smtp server, user name, password, which is made worse since some smtp servers require a user name/password and others don't.
If they do enter the wrong details (or they change) then you might need to have some way to send them older reports, or to have some other way of notifying them that you can't send email.
Email's great, but you might need an alternative method also.
Google for simple smtp server windows gives you this
To be honest if you are just sending things once a week email is your best bet, as it's not frequent enough to garantee that the user will be at his machine to accept some other sort of request, which would require you to write proprietory software.
You could alternatively post it to an irc channel, or write an MSN bot to message the user, the message would be sent as an offline message if the user was offline.
I'd still go for email, it's tried and tested.
For a simple SMTP server I use hmail. I configure it to accept all SMTP requests from the local machine, regardless of source and destination, and to deny any SMTP requests not coming from teh localhost. This will be fine if you have a centrally located application.
If you want to distribute the app you have a whole different situation; with a lot of ISPs putting restrictions on SMTP traffic your best option would be to allow users to put in their mail account details and then use that to send mail. This will ensure everyone can put in working settings. Then use whatever library or pre-made code exists for yoru language of choice to send an email using those settings.
Does it need to be a weekly digest? Instead, how about using Growl (or equivalent) to notify the user of the tasks being completed in real-time, in the background?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
From security reasons, is it worth encrypting user emails before putting them into the database?
I know we hash and salt passwords but that's another story as we do not really need password originals. With emails it is different.
Knowing that the decryption key will anyway be somewhere close to the database, does it make sense to encrypt emails? I suppose if someone gets into the system, they will find the key as well, if not immediately then eventually.
What are the best-practices? Are there any other options available if I run my own servers and not on a shared/virtual hosting?
EDIT: I intend to use SQL Server. And no, it is no corporate software with security requirements, just some entertainment site I have in mind.
If you're going to need the email address in the future, then you'll have to store them in plain text.
You could encrypt them, of course, however, this is effectively security through obscurity in this case. Basically, if your application's perimeter is secure, your data within it can be plain text. Encrypting here adds complexity to you working with the data, but doesn't really stop an attacker from getting your raw data.
As you say, if he gets through your perimeter defenses, he's likely to easily get your decryption key to decrypt the email data. Encryption may slow down the determined attacker slightly, but will not add any real security to your data.
The best scenario is to hash the email address (with salt!) and store that. This allows you to check the email address against an input value (for example) and verify that the email address input is the same as what you have stored, of course, the major downside for this is that you can't know what the email address is without that additional value, so if you're wanting to (for example) regularly email your users, you'll be out of luck.
I suspect you're storing the email address because it's useful data, and you will want to do something with it (like send an email :) in which case, encrypting just adds overhead to working with that data, whilst gaining very little in return.
In this case, I would focus on securing access the database itself (i.e. your "perimeter" defenses) and ensure they are as strong as can be, whilst leaving the data in the database in plain text.
Hopefully this answer will answer your question as well.
Is it worth encrypting email addresses in the database?
In short, no, it is not worth encrypting user email addresses. You're right in thinking that a database compromise will likely result in somebody also gaining access to the keys required to break your encryption.
In general I agree with others saying it's not worth the effort. However, I disagree that anyone who can access your database can probably also get your keys. That's certainly not true for SQL Injection, and may not be true for backup copies that are somehow lost or forgotten about. And I feel an email address is a personal detail, so I wouldn't care about spam but about the personal consequences when the addresses are revealed.
Of course, when you're afraid of SQL Injection then you should make sure such injection is prohibited. And backup copies should be encrypted themselves.
Still, for some online communities the members might definitely not want others to know that they are a member (like related to mental healthcare, financial help, medical and sexual advice, adult entertainment, politics, ...). In those cases, storing as few personal details as possible and encrypting those that are required (note that database-level encryption does not prevent the details from showing using SQL Injection), might not be such a bad idea. Again: treat an email address as such personal detail.
For your entertainment site this is probably not the case, and you should focus on prohibiting SELECT * FROM through SQL Injection, and making sure visitors cannot somehow get to someone else's personal profile or order information by changing the URL.
One of the most often-cited truisms in computer security is that the
only truly secure computer is one buried in concrete, with the power
turned off and the network cable cut.
With that in mind the best way to securely store email addresses? Dont store them at all!
tl;dr Do you need their email address, or a way of sending them emails? Either trust someone who will do a better job than you or don't use the email address at all.
Why do you need to keep a record of a customer's email address? The only reasons I have run into are:
Account confirmation & authentication
Transaction & Marketing emails
Confirmation & Authentication
The core of what we want is two step authentication: Something they know and something they have. Something they know is a password, and is easy to prove since they will be the only one who knows it. Something they have is harder to prove and traditionally we use an email address since it is easy to verify. These days though there are other things we can use:
Mobile phone
An account with a trusted website (Facebook, Google, Twitter)
Mobile phone verification is simple. Send them a sms using a service like twilio.com and ask them to text back a confirmation code. We now know that the mobile belongs to the customer who wanted to register. With OpenID you can verify existing accounts with other trusted sites, and the confirmation process is handled by them.
For the customer to authenticate then all they provide is either their mobile number and password, or an OpenID authentication token. Neither require a email address (well the OpenID provider might but thats not your responsibility).
If these are not an option then you can still confirm an email address and then use it for authentication. Confirmation only requires a unique token to be stored and a link to be sent to the email address. Store a salted hash of the email address, and use that to match the account in the same way we do passwords.
Transaction & Marketing Emails
The real reason why we want to store the email address! So we can send them offers of stuff we think they need so they can delete it without reading it. Seriously though is email the best medium for this? If we have an OpenID account then why not use that for notifications? Send a Facebook message or write on their wall, #mention them on Twitter, send a text message to their mobile, build an app and push notifications at them. There are so many channels much more effective than email.
If you want to use email then use a email platform like Mandrill and MailChimp. When they register create a subscriber in a mailing list on MailChimp. Store the subscriber id with the account. For transaction emails ( reset password, account updates ) fetch the subscriber and pass the stored email to Mandrill to send the email. For mass marketing just send to the mailing list in MailChimp.
The only thing stored in the database is the subscriber id. It also gives all the benefits of using a email platform, unsubscribes, open and click through rates, e-commerce tracking etc. Email platforms will do a better job of delivering emails that you. They will also do a better job at protecting the privacy of their data than you. Let them do the hard work of database security so you can focus on getting more customers.
I think that when people can come in your database you are anyway screwed :)
It doesn't make a lot of sense to just encrypt your email addresses. Beside that there will be a lot of other information in your database that you would not like to be gathered, the decryption key will be indeed within reach at the same time your database is open.
I would like to suggest to find your layer of security and data integrity on a higher level. So the prevention of people entering your database.
And why would email addresses be so important? Most people will anyway get spam or their email addresses will otherwise be available somewhere on the web.
Depends on how often you access the addresses. If you read them once in a while, it might make sense, but this would be one of the last security issues I would spend time on.
I do not encrypt user e-mails. The point is to protect the database; the keys are accessible anyway if you actually want to use the e-mails once they are stored.
Do check the address for validity and possible SQL injection, though.
If the application server and database are on separate servers, it would generally increase security to have all or parts of the database encrypted.
Even if they are on the same machine, a hacker may not figure out where your password is stored (although I wouldn't rely on that).
I generally wouldn't encrypt the emails at the application level, instead relying on database-wide encryption offered by most enterprise databases.
Of course if you're using something like MySQL, then you have no choice but to do it at the application level.
I normally tell my clients it isn't worth the trouble encrypting a database, however if you have stricter privacy requirements it may make sense to do so.
Encrypting database content is always a tricky consideration. Clearly the content is useless unless it can be unencrypted, and if that has to happen without human intervention, then you're storing both the cyphertext AND the key somewhere. If that somewhere is on the same machine, then one might wonder why you even bothered.
Well, there's a few reasons why you might want to do this. One is because you're required to do so because of some company policy. Another is that perhaps your database is housed in a more hostile environment than that machine that accesses it.
In general, encrypting database content isn't going to win you any awards, but if you can justify it, then you clearly have at least some motivation to do so.
yeah could be helpful for the user if you hash it with salt. I had a code before which i used that I use salt and hash then I can decrypt it. Flow is that once user will register you then hash and salt (encryption process) it. Then if you need to fetch the encrypted data there will be decryption.