My problem is not that I can't save emails to a database. Anybody can do that. Here is my question:
When a user makes an account on my website, they get an ID, User, Password, and Email address data. For the password I hash it so that if somebody hacks my website they wont see the real passwords. However, isn't having a bunch of email addresses saved, unprotected (like the users) a security risk?
I have never made a login system website before, and want to know if everybody else just leaves the email address unprotected in the database. (In other words, is it common just to save an email address to database as-is?).
Thanks.
Usernames and email address do not have the same sensitivity as passwords.
Passwords should be secured (hopefully with bcrypt) because if Alice has used the same password on Bob's Things as she has on Gmail then any attacker gaining access to the database on Bob's Things will then not be able to gain access to Alice's email account (nor those of the the other 10,000 users that regularly buy Bob's things and reuse passwords).
The email address cannot usually be hashed like passwords. If your system needs to send the user an email, it cannot do this if the email is stored in hashed form.
Plus there is less stuff an attacker can do with just the email address. Yes they could send phishing emails to your users, or they could try and password guess to gain access to accounts, however the complexity of securing the email address regarding its server-side storage is often not worth the effort.
You would be better off ensuring the interface to this database (i.e. your application and supporting infrastructure) is properly secured rather than trying to encrypt the email addresses within the database. Even if they were encrypted, key management then becomes the problem. Bottom line, the best you can do is secure your application against user enumeration if you want to protect people's email addresses from being easily discovered.
Generally:
1 - never save user's credit card number anywhere in your database, however you can save part of it if you really want to.
2 - always salt and hash user's passowrd
3 - no need to encrypt a user's email, if you really concern, encrypt it, not hash it
Related
I am developing an application (web\mobile). The user have to register the account using a form on the application (it contains some data as username and password).
These data have to be stored in a database table, these data travel on Internet so I think that it is not a good idea that the password is in clear.
I think that the client have to encrypt the password in some ways and that this crypted password have to be stored in the DB.
What could be a decent workflow for this task?
A common way to do this is to send the password as clear text via a HTTPS connection. HTTPS is a must when anything confidential is sent through internet, not only for passwords.
On the server, calculate a hash. There are many algorithms for this, some more secure than others. A hash function works only for one direction: the password cannot be derived from the hash. Store that hash to the database instead of the password. When a User logs in, calculate a hash from that password, and compare it to the hash stored to the database.
I working on security and I 'm storing a session key inside a cookie. I will use it to check if the user is actually connected and if he didn't tried to change some info.
at first I think to just check if the session key is inside the database, but I think it would be more secured to check if the current user has the session key instead of just finding a user that have that key and assume that he must be the one connected.
I know I should use session storage, but since I'm using AngularJS, I don't know how to achieve that, so no need to point out that I should use session instead.
-Would it be safe to put the username inside the cookie?
-Would just using the session key and assume that the user that got the key most be the connected one be a good idea (it would simplify some of my request to the database later on)?
It sounds like essentially what you are trying to achieve by storing the username in a cookie is to make the username a 2nd factor in a 2-factor authentication scheme. The problem is, the username always travels in a cookie alongside the session id and so when one is exposed, the other is too. So no security is gained.
Furthermore, there is no valid security argument to storing username in a client cookie and then trusting that this username is the same one associated with a session. The client can trivially change the value of the cookie before submitting a request. And any attacker that has already managed to have sniffed out the session id from a cookie could probably just have easily read the username cookie too, making a session hijack attack practically the same difficulty. At best, you've achieved no higher security and added unnecessary complexity to your code. At worst, you've betrayed usernames which wouldn't have otherwise have been visible to an attacker. eg. in the case of expired sessions.
OWASP Recommendation:
Session ID Content (or Value)
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
-- https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Content_.28or_Value.29
We have a really small setup but for the sake of keeping everything centralized we have a domain.
Occasionally managers will need to send email out as somebody else if they are not in the office, is it possible to add a secondary password or a master password to everyone's account through a group policy? That way if needed we could logon as that user and send out an email. Obviously it seems a little unusual but the password would only really be for one or two mangers. Not everybody.
I was thinking just giving passwords out to everyone and keeping track of them and not allowing them to change them, but seems bad practice.
This is not possible. You can configure Exchange (if you're using that) to allow people to send mail as or on behalf of other users.
I currently dealing with a ssh two factor authentication plugin.
It can be used like this:
$ ssh localhost
password: [ssh password]
Name: [your name]
OTPCode: [your code]
there is a list of username and OTP Secret in sqlite db.
if the sqlite db leaks, it is dangerous. should I hash the username and add a nick name to distinguish a which one is which. will this design cause any problem or is it neccesary?
To be honest, if someone gets hold of the database in the clear with the secrets in it, they aren't going to be too bothered about hashed/obfuscated usernames. They already have the secret information.
An attacker could realistic generate all the OTPs against all the secrets from the database in a fraction of a second and then try them all for any given username. Moreover if they have sniffed the username in the past and know when they authenticated (For TOTP), they can create all the OTPs for all the secrets in the database for that window and then see which secret corresponds to that user.
Basically if you loose your token's shared secret, loosing the corresponding username is going to be the least of your worries.
Focus on locking down the database or even better getting the authentication mechanism off of the machine.
I have an application that uses email addresses for user authentication.
I know that some universities use Shibboleth for user authentication, and I was wondering what the process is for being able to read emails from the university database that is used for Shibboleth. Note that I do not care about authentication through Shibboleth, I only need to be able to read the email addresses.
Is it general for all universities that use Shibboleth, or is each a unique case?
Any links to documentation on how to do this process would be greatly appreciated. Thank you.
Shibboleth can be configured (IdP-side) to release user attributes along with authentication data, for example the user's email address. Client-side, assuming you're going though shibd, you'll need a setting in your attribute-map.xml that says "map attribute with OID x.y.z.a to environment variable USERMAIL" and then you get the result in that environment variable. The example config should already contain it.
This would be the same for everybody insofar as the OID for "email" is always the same, but you'd have to negotiate with the IdPs (universities) or their federations so that they will actually release that attribute to you.
Shibboleth is used by many institutions, but by no means all. Many use Athens, proxies or IP recognition, among other things.
As far as I am aware, a user's email address is not tied directly to the Shib system. When a user tries to access a Shibboleth-protected resource they are taken to their institution's login page to authenticate themselves. They might enter their email address to authenticate or they might enter a username, they might be auto logged-in based on their IP address, or something else.
The institution does send back an affiliation through Shib data transfer upon successful login, something like student#brown.ac.uk but this is not necessarily the email address the user used to login. I guess they could send that but it has not been used in system's I've worked on.
Shibboleth is commonly used to check that the user is from an institution that has purchased access to a protected resource rather than identifying a particular user from that institution so the user's email isn't needed.
Not sure if this helps at all: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation