Our services are expanding in a lot of countries that obey GDPR like European countries. Each country has its own service. We want users to be able to log in and even share their own information across countries/services.
A simple solution is that we will create one identity provider in our headquarter and authenticate users globally. But our consultant said that it will violate GDPR.
Can I save only hashed user email and password in our headquarter data center?
I very much appreciate your help. Thank you so much for reading this.
Related
Given the increasing concerns in data privacy, is it possible to build a web app that provides a driven user experience (aka different outcomes on different users based on their specific profiles) without sending any personal information that can be tracked, hijacked or forced by any entity on the web app's servers ?
The question is somewhat vague, but due to the fact that HTTP is stateless, you'll need users to send some kind of information, at the very least user registration and login data to identify them and store their identity in some kind of storage (ex. cookie).
If you dont want the users to post any data, you wont be able to personalize the experience, just provide the same experience to everyone every time they enter your website.
I think you can do this, but you will need to identify users at the start, and then unidentify them later - for example, get them to register with an email address, confirm that address, then create an identifier derived from that address (e.g. a hash or random number), switch to using it as a user name and delete the email address. Then you will be at a point where they can log into an account, but you hold no personal identifiers on them.
I have a set of encrypted financial data for investors and need to store it in a database. The investors must be able to see the data when logged in to the app but the developers and everyone else mustn ot be able to see it.
Additionally the investors are not tech savvy and can not be given a key to use apart from a username and password.
What technologies/encryption approaches can I take with the app so that the financial data can be kept secret from me and other developers by the company, I'm assuming they encrypt it before uploading it for example, but allow the valid users to access it.
Is there a way to do this without putting a technical burden on the investors so that they don't have to have anything more than a username and password whilst also not storing their "keys" in the database so that a developer could technically decrypt it.
For a web application, where we need to store and manage users (SSO or openauth or what not is off the table), where we manage important business data, how risky is it to use an email address + password as the sign in?
For the last 15 years or so, encryption and protection techniques have improved, but we continue to use a proprietary user id, akin to using your bank card number for online banking; an id that will not be reused elsewhere. Customers and product owners are pushing to use email address because it is easier to remember.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
I'm looking for some article or argument why using email+password for a site with sensitive business/financial information would be dangerous; or why it is not so bad. Again, I realize that provisioning our own accounts is not the ideal thing and am not looking for solutions at outsourcing authentication.
The "risk" of using a single authentication method for signing onto your application is difficult to determine without a risk assessment, and clearly defined system boundaries.
NIST 800-61 and NIST 800-63 gives guidelines on authentication methods for different levels of sensitive systems (in your case, a application). It will give you ideas on how to present your argument, and maybe an alternative solution, i.e., multi-factor authentication if the customer wants to authenticate using an e-mail address. This would mitigate the risk associated with malicious websites which collected e-mail addresses and passwords.
Keep in mind, password policy can also be managed to mitigate the risk behind a single authentication method using an e-mail and a compromised password associated with that e-mail.
All in all, it's not the ID that is important, but the authentication method and policies in place to mitigate the risks.
Using email + password as credentials is the widely accepted method of allowing users to log into sites on the web.
The advantage of using email is that everyone remembers their email address, whereas people will have difficulty in remembering which username or user ID they first signed up with if this is not their email address.
Username should not be considered private. This is the job of the password. Encourage your users to use a password manager such as LastPass where it can generate a 20 character completely random password (128 bits - uncrackable) which is different per site. LastPass will remember the username if this is not their email, so that solves this problem, however not using email can bring other problems such as username enumeration. If any signup function asks for a user to specify their username and you say that it is already in use, an attacker can use this to narrow the list of users in order to prepare for a password guessing attack. If you ask for email as step one of password reminder or signup forms, the system can send an email with a password reset link if already registered, or send an email with a link to the next step in the registration process if not.
In the end it all comes down to the value of the data your application is protecting. Adding two factor authentication is always a good step and can protect against password guessing and password reuse.
SSO or openauth or what not is off the table
Why is the case? Can't you use OAuth with claims based authorisation? You can still secure your application and make sure only the correct business users have access - it would just be that another entity is managing access for you.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
Credential harvesting?
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.
I am considering adding OpenID to our customer facing admin and control panel areas...
1 - Associating OpenID's With Existing Accounts
For customers that already have accounts with us, I'm thinking they would need to login using their existing account number that we issue and then I'd have a mechanism to associate their OpenID with that account in their account management area (call it 'OpenID Manager' for the sake of argument).
In the 'OpenID Manager', presuming the user already has an OpenID, would I authenticate the user against their OpenID then associate with our generated account number for future OpenID logins (assuming that they authenticated ok)?
2 - Sensitive Data
Although we don't store full credit card data in our DB there is other data that is sensitive, invoices, domain reg details etc. After reading this article http://idcorner.org/2007/08/22/the-problems-with-openid/ I'm a little cautious about the idea of using OpenID in this way, what's the general consensus with you folks?
It seems to me that a lot of the arguments against OpenID are either made out of ignorance or by people with an axe to grind.
For example, the document you link to complains that identifying yourself with a URI is "dehumanising and more than a little frightening". Is that a legitimate complaint, or something written by somebody desperate to find things to complain about?
The two major things that get brought up are phishing and compromised accounts and these arguments have been rehashed so many times, it's hard to take somebody seriously if they bring them up yet again with no new points to make.
Phishing protection depends on the provider. Some providers offer much better security than typical websites ever would. Some providers just offer the typical username and password. Either way, if an account is compromised, that's something between the user and their provider, it's not your concern. You don't worry that the end-user has a keylogger installed on their computer, do you? That's because their local security isn't your responsibility, even though it might be used to gain access to their account. Likewise with OpenID - its security is not your responsibility.
If you compromise an OpenID, it gives you access to more than a single website. Sure, but the same is true for email. Just say you've forgotten your password, and you get sent a new one. You now have access to every account they've registered with that email address.
OpenID is no worse than the status quo, and it's significantly better in many circumstances, especially for informed users. If you are still wary of it, then just make it optional, so only the informed users use it.
I'd allow the registration of multiple OpenIDs with a particular account. That's a nice feature to have because it allows users to migrate between OpenIDs should the need ever arise.
That said, the idcorner link raises a good point. I think he massively overblows the security issue and makes many idiotic assumptions about how OpenID providers work, but that OpenID really isn't intended to replace all forms of user authentication. It's designed to make it easy for "drive-by" users to interact with a site with some form of basic authentication.
Ever been to somebody's blog, want to post a comment, but first you have to step through a 3-page registration? OpenID solves that problem.
Want to post a quick bug report on a public tracker but need an account first? OpenID to the rescue.
Want to store sensitive proprietary data in a web-accessible way and provide access only to people who are trusted? OpenID is not the solution.