If a hacker has access to the hashes in my DB, he has access to the rest of the information in the DB anyways. So why would he bother trying to decrypt the passwords? Should I be storing the passwords on a different server to the rest of my data? That is the only scenario in which I can envision it being useful.
Sometimes a hacker doesn't get full access to your DB. Sometimes they find a little SQL injection hole or other weakness that someone didn't code correctly, and so they can only do simple things at first like print out database cells one at a time. If they can print out a real password all of a sudden things get much worse.
Things happen: backup tapes are lost, accidentally thrown away, or stolen. A retired system wasn't wiped properly. A breach elsewhere leads to accidental exposure of a database. If a hacker gets access to a snapshot like this he can learn a lot about your system. But if the passwords are still hashed he can't also use the system to do something malicious, like log in as a different user and start changing things.
I've heard that most hacks are an inside job. Better to remove the ability even for people you trust to log in as others.
It's not about just you. Users tend to share passwords across systems. Maybe some day (God forbid) you have a breach that has nothing to do with passwords, but in the course of that breach your authentication tables will be one of the attacker's targets. If you store passwords in plain-text, you have also just compromised user accounts at many other services, and your very bad day just got quite a lot worse.
If you think this kind of thing doesn't happen, go talk to the guys at reddit.
People often use the same username/password for different accounts on other websites (including, e.g., online access to bank accounts).
Once you've discovered this hack and have secured your database, the hacker will still have the ability to login to your user's accounts.
Best security practices suggest:
You should use a unique (userId, password) pair for each account you have. But most people use a single pair for many resources (email, bank, etc). An attacker can steal them from one resource and use them to access another. Hashing the passwords with salt—see http://en.wikipedia.org/wiki/Salt_(cryptography)—prevents this sort of attack.
You should encrypt all sensitive data in your database, not just passwords. Your point that someone might steal your entire DB (or your server) is perfectly valid.
You should separate your web server from your database and any other precious resources, to quarantine an attack to your least valuable asset.
There are business reasons to hash passwords, as well. Remember, hashing means you do not store your users' passwords anywhere on your equipment.
Depending on the laws that apply, you may be required to do this in certain situations.
You greatly reduce your exposure if your data is stolen.
You're safer from social engineering attacks, in which an attacker impersonates a valid user and cajoles an employee into revealing a password. See http://en.wikipedia.org/wiki/Social_engineering_(security).
Should I be storing the passwords on a
different server to the rest of my
data?
This adds complexity to your system, but if it's something you can do it's definitely an improvement.
Note that using authentication servers such as Kerberos, RADIUS, or Windows domain authentication effectively put you passwords on another server.
Because even if you have access to the data, having access to the APPLICATION is actually more important. The Application makes it much easier to manipulate the data, for example.
Hashing the password prevents casual exposure from all eyes.
For example, you may well have the same password across several sites. A quick glance at the DB not only compromises your application, but perhaps several others.
It's just a good, solid practice to hash you passwords.
Mainly because it's nearly trivial to do it well, and the benefits can be very high.
Sometime, you don't know who will be the system administrator. You still want to protect your users from them.. So, by hashing passwords and all important information (such as credit card), you make it really harder for the hacker or administrator. And, I think password should never be written literally. I mean, I used a password since 2 years and I have never seen it written down.. why an administrator that I don't know should see MY password ?!
Using a hashed password prevents the attacker from being able to log into your app even if they know the hash. Your login page asks for the original password, so to log in using it, they'd have to reverse the hash (compute a collision). Using a rainbow table, that's fairly trivial for MD5, for example, which is where salting comes in. Then the attacker needs to know 1) the way you combine the salt and the password (not much security there), 2) the salt (which is likely in the db already) and 3) they have to compute that value for each combination of password and salt. That's a lot more than just computing hashes of common passwords and looking for a match.
When a hacker access your database it does not mean that he can access the procedural code, those procedures can alter databases outside the hacked database boundaries or inclusive can alter other procedures.
By the way now I´m going to ask you something: If a user is hacked and someone has his or her password, how do you make clear that it is not your application or security fault?
If you don't have stored passwords you don't have such responsability!
If an application is to show grade information at the university then having access to the password will allow you to get the grades for that person. If the password also allows you to log into the online course system then you can submit tests as that user.
If the data is even more sensitive, such as credit card numbers or health records, you are open to lawsuits.
Odds are that the more sensitive information may be on a more secured system, behind stronger firewalls, so they may have found a weakness by hacking into the authentication database.
By hashing the password, then those that have access to the authentication database can't see the password and so log into the very sensitive system as a different user.
The whole LinkedIn "scandal" was all about leaked hashed passwords.
As I see it, security isn't about anything other than making data retrieval inconvenient.
And by inconvenient in the ideal case we mean it'll take you millions of compute years to access (ie single CPU trying to guess at password would take on the scale of millions of years).
If you store passwords in cleartext, that takes a total of 0 compute years to access. The LinkedIn scandal would have looked much worse. All you have to do is SELECT * FROM USERS (either via injection or an insider).
People often reuse passwords, so if people learn your password, it means a whole world of data becomes accessible to them (not just their LinkedIn, for example). So it becomes a very personal risk. As a webmaster it's rude not to at least hash passwords: you don't have that much respect for your users to take the basic step of trying to protect their information.
Even if the hashed password can be cracked, you're at least taking the bare minimum step to protect your users.
If he can decrypt the passwords, he can probably get access to your user's accounts on other sites as well (as, no matter how many times we tell people not to re-use passwords, they do). Storing plaintext passwords is a good way to give away all your users' PayPal, eBay & Amazon accounts.
Related
I'm on my last steps to open my website, but the only thing that drove me crazy is the php user management. I found a lot of resources about building these systems and I believe that I can write them in my own way. The thing is that when it comes to security I get so freaking out what to go with. For example, when it comes to sending sensitive information over SSL, some people suggest to make sure that the info is encrypted in the registration form so that attacker can't hack it. And some other suggest to make sure that the debugging messages don't show when an error happen so that the attacker can't retrace the links .etc.
now as I read from here and there that md5 is not safe anymore so I'm wondering how would hash new user password and etc... I found a link to some programmers who already offer some user management, but not sure if they are good enough since I'm concerned about security as a priority CodeCanyon
so now what are the security measures that I have to be focusing on?
are there any resources related to that?
Thanks,
You don't have to (you shouldn't) choose between the different things people tell you to implement. Good security is always layered, meaning that you implement as many protections as you can. This approach has multiple purposes. Each layer can prevent different attacks. Each layer can prevent attackers with different experience. Each layer can increase the time needed for an attacker.
Here are some tipps useful for authentication systems.
Don't show debugging outputs
Don't use MD5 hashes. SHA2 or even better, bcrypt are much better
Use salts when storing passwords
Use nonces on your forms (one time tokens)
Always require SSL encryption between server and client
When accessing your database on the server, make sure that information leakage or its client-side manipulation not possible (eg.
avoid injection attacks, with database drivers use prepared
statements, etc.)
Make sure all failed logins (no matter what the reason) take the same amount of time to prevent timing attacks
When a logged-in user starts a risky operation (changing pwd, payment etc.), re-authgenticate him
Never store passwords cleartext, not ever, not anywhere
Require a minimum complexity for the password
!!! Secure your php sessions (another large topic, worth its own discussion) -
As you can see, there a lot you can do (and more people will probably tell you even more stuff), what you really should do depends on the risks you are willing to accept. But never rely on a single security measure, always have a layered approach.
Answering your direct question: It has been proven that MD5 does have collisions and there are rainbow tables floating around (see Wikipedia). PHP does have quite some hash functions available all having different advantages and disadvantages. Please also see the comment section on php.net.
Concerning general web application security I'd recommend you take a look at the OWASP project that is about making web applications more secure. A good start would be to take a look at the Top Ten security vunerabilities ("Top Ten" in the blue box).
use sha1 for storing password , prevent sql injection and xss script as input field.
session hijacking , fixation prevention.
At first you should send your data via SSL (TSL) to the server, this will encrypt. Also you should use a CSRF protection for any form you send to the server.
When you have implemented your functions and they work you should try to hack your site by yourself. Try to inject SQL, JS through the forms, try to manipulate the date after the form was send, you can also try to produce erros that will be written to you PHP error log even that could be executed if your server settings are weak. (http://en.wikipedia.org/wiki/Hardening_(computing))
When you store the password in your database use an seeded hash function, if anyone is able to hack your database and get the hashs he will not be able to encrypt them without the seed.
Your will find many information about all the techniques via google.
let's just assume a simple non salted hash function, just a plain old $hash = md5($pass).
Premises:
the password hashing all takes place server side, and the hashes are stored in the database. The client has no way to see these.
a rainbow table attack must have knowledge of the hashes in order to retrieve passwords.
Given premise 2., that would mean that the hacker already has control of the database, in which point you have a much bigger problem on your hand.
So, is the point of trying to foil a rainbow table attack simply to protect the retrieval of passwords from an already compromised database/system. Is it that simple or is there something else that I am missing.
I'm already familiar with password hashing techniques, but am just wondering why there is so much hype about rainbow tables. Thanks!
Yes.
Many people use the same password for everything. Compromising the original password (as opposed to simply changing it to something you know) can often give an attacker access to someone's accounts on other services.
Rainbow tables are also much less computationally intensive (simple lookup) than a dictionary attack (which requires hashing) or brute force (which requires a lot more hashing).
Use strong, unique passwords!
Password compromise doesn't require control of the database. What if I break into your car and steal a stack of DVDs with database dumps? You do back up your database, right?
As mentioned, people use the same password for multiple sites. HBGary fell victim to this when they were hacked by Anonymous recently. One server with an SQL injection vulnerability turned into a much larger compromise.
If I have access to your database for five minutes and get the hash, I now have access to your account until you change the password.
Salt is cheap.
You should use a key derivation function anyway, not a salt.
Most of the time, data-theft from databases succeed through injection; sometimes even blind injection.
An attacker who has found a database injection exploit in one of your scripts doesn't gather any control over the rest of the system until he is able to retrieve some kind of higher credential - which could be the admin's password.
If you (being the admin) have your password stored as a simple md5() hash together with the rest of the users, and the attacker manages to retrieve it - he could eventually overtake your system by using a rainbow table to look it up.
If I understand them correctly, rainbow tables remove the computational burden of calculating the hashes (which is deliberately high), so attacking is faster.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
PHP 2-way encryption: I need to store passwords that can be retrieved
I know that the best practice for storing user passwords is to store only an irreversible hash of the password.
However, I am developing an application where I will need to store a user's login information for another web service -- I'll need to periodically log them in and perform some maintenance tasks. Unfortunately, the service doesn't offer authorization tokens so I (very apprehensively) have to store the passwords in a way that I can access their plain-text values. I don't own or control the service to which I am authenticating, and the only method is to 'borrow' a users username and password and authenticate.
I am planning to AES_ENCRYPT the passwords in the DB, which means that if somebody is somehow able to access the DB they won't be able to get the plaintext. However my code will need to have access to the key to unencrypt them, thus if the entire server is compromised this is no protection and the passwords will be revealed.
Aside from the above-described encryption, are there any best practices or steps I can take to do this as safely as possible?
EDIT
I know that whatever I do, ultimately the passwords must be accessible in plaintext and so a compromised server means the passwords will be revealed, but I am wondering what steps I can do to mitigate my risk. E.G. encrypting the DB protects me in the situation where the DB is compromised but not the entire server. Other similar mitigating steps would be much appreciated.
However, I am developing an application where I will need to store a user's login information for another web service -- I'll need to periodically log them in and perform some maintenance tasks.
OK... I read through the answers and the comments, and about all I can say is I hope you have crack legal team. It sounds to me like the service you are offering is predicated on user trust. It's good that it's a user-controlled switch, and not something being helpfully done behind their backs, but I think you want a really iron clad service agreement on this.
That said, there's a lot of security paranoia you can invoke. You'll have to figure out how much you want to go through based on the harm to your product, your company and users if a break in occurs. Here's thoughts:
Data storage - store the passwords far away from where an attacker can get in. Highly access controlled files, a database on a back end machine, etc. Make any attacker have go to through layers of defense just to get to the place the data is stored. Similarly have network protection like firewalls and up to date security patches. No one thing works in isolation here.
Encryption - any encryption technique is a delaying tactic - one the attacker has your data, they will eventually crack your encryption given an infinite amount of time. So mostly you're aiming to slow them down long enough for the rest of the system to discover you've been hacked, alert your users, and give the users time to change passwords or disable accounts. IMO - either symmetric or assymetric cryptography will work - so long as you store the key securely. Being a PKI person myself, I'd lean towards assymmetric crypto just because I understand it better and know of a number of COTS hardware solutions that make it possible to store my private key extremely securely.
Key storage - your encryption is only as good as your key storage. If the key is sitting right next to the encrypted data, then it stands to reason that the attacker doesn't need to break your crypto, they just use the key. HSM (hardware security modules) are the high end choice for key storage - at the upper ranges these are secure boxes that are tamper proof which both hold your keys and perform crypto for you. At the low end, a USB token or Smart Card could perform the same function. A critical part of this is that ultimately, it's best if you make an admin activate key access on server startup. Otherwise, you end up with a chicken and egg scenario as you try to figure out how to securely store the ultimate password.
Intrusion detection - have a good system in place that has a good chance of raising alarms if you should get hacked. If your password data is compromised, you want to get the word to your users well ahead of any threat.
Audit logging - have really good records of who did what on the system - particularly in the vicinity of your passwords. While you could create a pretty awesome system, the threat of privileged users doing something bad (or dumb) is just as bad as external threats. The typical high end auditing systems track high privilege user behavior in a way that can't be viewed or tampered with by the high privilege user - instead, there's a second "auditor" account that deals only with audit logs and nothing else.
This is a highlight of the high points of system security. My general point is - if you are serious about protecting user passwords, you can't afford to just think about the data. Just encrypting the passwords is not likely to be enough to really protect users and safeguard trust.
The standard way to approach this is to consider the cost of explotation vs. the cost of protection. If both costs are too high for the value of the feature, then you have a good indication that you shouldn't bother doing it...
As you said, your code will eventually need the key and so if the server is compromised, so will be the passwords. There is no way around it.
What you can do is have a very minimal proxy whose only job will be to have the passwords, listen to the requests from your main application, connect to the service in question, and return the response to your application. If that very simple proxy is all that is running on a server then it will be much less likely to be compromised than a complicated application running on a server with many services.
I'm looking for studies on the security effect of frequent password changes, looking at the security benefits / problems from having a mandatory password change every one or two months or similar.
Does anyone know of any?
Here is a research article on password policy. It mentions the frequency at which people should change their passwords and some other really interesting stuff. Below is an extract.
Some experts say that periodic
password changes will reduce the
damage if an attacker intercepts a
password: once the password is
changed, the attacker is locked out.
This assumes that the recovered
password will not give the attacker
any hints about the victim's current
password. In fact, periodic password
changes tend to encourage people to
design sequences of passwords, like
secret01a, secret01b, secret01c, and
so on.
This allows users to easily choose and
remember a new password when the old
one expires. Such sequences are
usually pretty obvious to an attacker,
so any one of the victim's old
passwords will probably provide the
attacker with a reasonably small
number of passwords to guess at.
The TechReport Do Strong Web Passwords Accomplish Anything? states “changing
the password frequently helps only if the attacker is extremely slow to exploit the harvested credentials.”
In my opinion, forcing people to change their password too often, reduces security because the only way people can remember so many passwords, is to start using stupid passwords like Computer123 or January1 followed by February1 etc...
A better idea is to reduce the frequency and then train people how to create strong passwords.
While not exactly the study you're looking for, it is closely related and might push you in the right direction. I have seen a few studies on the specific topic you're looking for, but can't find the references just yet.
Microsoft Security Guru advice: "Write down your password"
There are a number of bad things that can happen with passwords, and want to mitigate as many as possible without creating new problems. The "change your password" policy is there to mitigate the damage over time that could be caused if your password gets out, by limiting the window of opportunity for an attacker. While not the end-all of security measures, it can sometimes make a huge difference. As a security consultant, I have personally made (this year alone) many tens of thousands of dollars cleaning up messes that could have been avoided entirely if the company had changed important passwords at least yearly.
The danger of changing your password frequently is that you'll pick poor passwords. This makes the situation even worse, because it now allows attacks that would have otherwise not been possible.
The new wisdom, as mentioned in the linked article, is pick (or be assigned) a random password, possibly changed on a regular basis, and write it down somewhere that you keep safe. Obviously you don't leave it with your computer any more than you would leave you keys with your car. The justification is that people are already trained to know how to secure "things" but are naturally poor at securing information. So if you turn the password into a thing you can hold, then you can just secure it the same way you secure your keys. In practice, this works very well, however it tends to make IT departments nervous.
Update, August 2016:
This article: "Frequent password changes are the enemy of security, FTC technologist says" http://arstechnica.com/security/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/?imm_mid=0e6947&cmp=em-webops-na-na-newsltr_security_20160809
has been showing up everywhere this week, including Bruce Scheier's blog, O'Reilly's Security Newsletter, ArsTechnica, Slate, and NewsCombinator, and may be just exactly what you'd asked for earlier this year.
It references:
https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf
TL;DR summary: Stop expiring/changing passwords. It's a really bad security practice.
I don't know of any studies that exist, but to get you thinking about both sides of the issue, here's a paper against forcing password changes:
Managing network security — Part 10: Change your password
And an instructional site for an educational institute that makes at least a somewhat compelling case (Written by a Ph.D.) for forcing users to change their passwords frequently. These are the main arguments the site gives FOR forcing password changes, after the link to the page:
"Why Do I Have to Change My !#$%#* Password?"
If you're required to change your
password at least every six months,
someone who's hacked your password
and has been accessing your account
without your knowledge will
immediately be shut out once your
password is changed. Some may think
this is an uncommon scenario, but
people commonly sell an old computer
and forget to erase passwords they
may have saved for dialing in or for
accessing their email.
If you change your password at least
every six months, hackers who may be
trying to crack your password using
brute force (as described above)
basically need to start over because
your password may now have been
changed to some pattern they've
already tried and rejected.
Forcing a password change also
discourages users from using the same
password on multiple accounts. (Using
the same password on multiple
accounts is bad because then your
password is only as secure as the
least secure of the systems sharing
that common password, and if your
account does get compromised, the bad
guy suddenly has access not just to
one account, but to multiple
accounts, magnifying the scope of the
problem).
As far as "research" goes, these might not cut it, but seem to be at least a good introduction to both sides of the argument.
It's not a study, but Gene Spafford posted a short article that discusses the reasons why a policy of frequent password changes doesn't make much sense:
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
Passwords should be changed when you believe that your password may have been or may soon be compromised. Otherwise, it is usually a useless waste of time, and actually a security hazard. See this link:
http://old.news.yahoo.com/s/ytech_wguy/20100413/tc_ytech_wguy/ytech_wguy_tc1590
This is an excellent paper published in an ACM publication (from 2010) that discusses the cost-benefit analysis of security and user expectations.
http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf
It does make the claim that changing passwords is certainly good advice, but it may not be worth the cost to the users since there is so little evidence to support the idea that we are safer with more frequent password changes. It really is such a good article.
I'm already using salted hashing to store passwords in my database, which means that I should be immune to rainbow table attacks.
I had a thought, though: what if someone does get hold of my database? It contains the users' email addresses. I can't really hash these, because I'll be using them to send notification emails, etc..
Should I encrypt them?
Bruce Schneier has a good response to this kind of problem.
Cryptography is not the solution to your security problems. It might be part of the solution, or it might be part of the problem. In many situations, cryptography starts out by making the problem worse, and it isn't at all clear that using cryptography is an improvement.
Essentially encrypting your emails in the database 'just in case' is not really making the database more secure. Where are the keys stored for the database? What file permissions are used for these keys? Is the database accesable publically? Why? What kind of account restrictions are in place for these accounts? Where is the machine stored, who has physical access to this box? What about remote login/ssh access etc. etc. etc.
So I guess you can encrypt the emails if you want, but if that is the extent of the security of the system then it really isn't doing much, and would actually make the job of maintaining the database harder.
Of course this could be part of an extensive security policy for your system - if so then great!
I'm not saying that it is a bad idea - But why have a lock on the door from Deadlocks'R'us which cost $5000 when they can cut through the plywood around the door? Or come in through the window which you left open? Or even worse they find the key which was left under the doormat. Security of a system is only as good as the weakest link. If they have root access then they can pretty much do what they want.
Steve Morgan makes a good point that even if they cannot understand the email addresses, they can still do a lot of harm (which could be mitigated if they only had SELECT access)
Its also important to know what your reasons are for storing the email address at all. I might have gone a bit overboard with this answer, but my point is do you really need to store an email address for an account? The most secure data is data that doesn't exist.
I realize this is a dead topic, but I agree with Arjan's logic behind this. There are a few things I'd like to point out:
Someone can retrieve data from your database without retrieving your source code (i.e. SQL injection, third-party db's). With this in mind, it's reasonable to consider using an encryption with a key. Albeit, this is only an added measure of security, not the security...this is for someone who wants to keep the email more private than plaintext,
In the off chance something is overlooked during an update, or an attacker manages to retrieve the emails.
IMO: If you plan on encrypting an email, store a salted hash of it as well. Then you can use the hash for validation, and spare the overhead of constantly using encryption to find a massive string of data. Then have a separate private function to retrieve and decrypt your emails when you need to use one.
In common with most security requirements, you need to understand the level of threat.
What damage can be done if the email addresses are compromised?
What's the chance of it happening?
The damage done if email addresses are REPLACED could be much greater than if they're EXPOSED. Especially if you're, for example, using the email address to verify password resets to a secure system.
The chance of the passwords being either replaced or exposed is much reduced if you hash them, but it depends what other controls you have in place.
I would say it depends on the application of your database.
The biggest problem is, where do you store the encryption key? Because if the hacker has excess to anything more than your DB, all your efforts are probably wasted. (Remember, your application will need that encryption key to decrypt and encrypt so eventually the hacker will find the encryption key and used encryption scheme).
Pro:
A leak of your DB only will not expose the e-mail addresses.
Cons:
Encryption means performance loss.
Allot of database actions will be harder if not impossible.
Don't accidentally conflate encryption with obfuscation. We commonly obfuscate emails to prevent spam. Lots of web sites will have "webmaster _at_ mysite.com" to slow down crawlers from parsing the email address as a potential spam target. That should be done in the HTML templates -- there's no value to doing this in persistent database storage.
We don't encrypt anything unless we need to keep it secret during transmission. When and where will your data being transmitted?
The SQL statements are transmitted from client to server; is that on the same box or over a secure connection?
If your server is compromised, you have an unintentional transmission. If you're worried about this, then you should perhaps be securing your server. You have external threats as well as internal threats. Are ALL users (external and internal) properly authenticated and authorized?
During backups you have an intentional transmission to backup media; is this done using a secure backup strategy that encrypts as it goes?
Both SQL Server and Oracle (and I believe also others DBs) support encryption of data at the database level. If you want to encrypt something why don't simply abstract the access to the data that could be encrypted on the database server side and left the user choose if use the encrypted data (in this case the SQL command will be different) or not. If the user want to user encrypted data then it can configure the database server and all the maintenance work connected with key management is made using standard DBA tool, made from the DB vendor and not from you.
A copy of my answer at What is the best and safest way to store user email addresses in the database?, just for the sake of the search...
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 many sites the above 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.
It's worth to encrypt data in Databases, it's not making it a bit more difficult but way more difficult when its encrypted in the right way so stop philosophy and encrypt the sensitive data ;)
#Roo
I somewhat agree to what you are saying but isn't it worth encrypting the data just to make it a little more difficult for someone to get it?
With your reasoning, it would be useless to have locks or alarms in your house, because they can also easily be compromised.
My reply:
I would say that if you have sensitive data that you don't want to fall in the wrong hands, you should probably do it as hard as you can for a hacker to get it, even if it's not 100% fool proof.
I miss one important answer here.
When you have European users, you have to comply with the GDPR rules.
Email addresses are considered personal data meaning Art.5 does apply on email addresses.
processed in a manner that ensures appropriate security of the
personal data, including protection against unauthorised or unlawful
processing and against accidental loss, destruction or damage, using
appropriate technical or organisational measures (‘integrity and
confidentiality’).
Of course this does not say that you must encrypt email addresses. But by encrypting the data you do protect it from snooping employees. And protect yourself as a developer from requests to make a manual change in the database.
You really have to weigh your worst case senario of someone obtaining those email addresses, the likelihood of someone obtaining them, and your extra effort/time needed to impliement the change.