Let's say i'm writing a program or app that requires me to authenticate users on their behalf, i.e. ask a user for their credentials to log in to a website or something to retrieve and process data.
How can i do something like this in such a way that the user's security is guaranteed, preferably so that i can't even see the credentials they've provided at all. And if this is not possible, how can users be assured that their privacy and security is not compromised in any way.
Simplest answer, but probably not useful to you is:
You can't guarantee privacy and security are not compromised! And as the admin on the server, if you receive and store user credentials, you could access them.
Immutable Law #6 of Security: A computer is only as secure as the administrator is trustworthy
So think about what level of security you would accept as appropriate.
You could use something like OpenID, like StackExchange uses - it removes the authentication piece from their responsibility. Only the OpenID provider receives credentials - SE just gets a token from them.
Related
I have read a lot about OIDC and OAuth2, I know the id token is mainly used for the client to know who the user is and whether the user is still online currently.
Furthermore, Id token can prevent a class of impersonation attacks [You can find more details in this article].
But what if the id token is stolen? Can the attacker uses the id token to impersonate a user?
In our project, we just ensure https besides the OIDC. What else security consideration should I take to mitigate the impersonation attacks?
The goal or purpose of OIDC is not to be more secure than OAuth2, and this kind of comparison doesn't make sense. They solve different problems.
Let's start with OAuth2. In very short and somewhat simplified, OAuth2 solves the problem when a website holds data of a user, and that user wants to grant access to some of their data to another website. Say you have a Facebook account, but want to allow my application to access some of your data on Facebook, or for a more concrete example, you want to allow my awesomeapp.com app to post a link to your Facebook wall. For this, my website redirects you to Facebook, you log in, get an access token, and send that access token back to my website so that I can use it in your name to get what you allowed me to.
Note that there is one thing missing. I have no idea who you are. I just had an access token, with which I can do stuff, but I don't have identity info about you. Sure, this can be abused in different ways, the access token can hold your email address or whatever, but it's limited, the size matters, and there is no standard way.
At least not until OIDC comes in the picture. OIDC provides the identity element.
The purpose of the ID token is to provide identity info, to tell me claims about who you are. It may claim what your email address is, what security groups you are in, which company you work for, or anything else. Also it may be used to download more claims, in case they don't all fit in the actual token (see userinfo). These claims come from the Identity Provider, say Facebook, which my application then has to trust of course, i.e. I will believe whatever Facebook tells me about you.
This is all possible with pure OAuth2, but there is no standard, well known way to do so (or well, it is OIDC :) ). You could invent and implement something yourself, but these things are more complicated than they may first seem to be. That's why OIDC was invented, so you don't have to. But after all, OIDC is just a way to use OAuth2 to provide identity. In the end, it's just an extended OAuth2 if you like.
As for what security considerations you need to take into account - this part of your question is way too broad and can't be answered unfortunately. Security is a very complex topic.
I'm not really a security purist so my additions to Gabor's points are from a more practical viewpoint, as someone responsible for building well architected UIs and APIs:
An id token represents proof of authentication to a UI
An id token is NEVER used by APIs, which must use access tokens instead
An id token is the only type of token a UI should ever read, and it is mandated to have a JWT format
For Web UI logins an id token provides extra security, since it enables the UI to validate tokens and protect against some types of token substitution attack - so yes - OIDC is more secure
An id token is sometimes needed in order for logout to work
You should ALWAYS use a certified security library that does this type of work for you, rather than reading tokens directly in your own code.
I am running the open source parse-server and have well secured my database. However, my application requires administrator users which need to have the power to read and write nearly all the data. This is a security concern which I would like to address with two-factor authentication, though I am open to other ideas (IP whitelisting, cookies, or whatnot).
Setting this up on my client apps is straightforward enough and I have done that, but I would like to be even more secure so that if malicious agents have my Application ID (which is basically public) and somehow obtain an admin's credentials, they still cannot gain access.
I am puzzled as to how to accomplish this with the parse server as it is today. There are no Cloud Code triggers for User sign-in, so I can't enforce any MFA on the Parse server itself, as far as I can tell.
One possibility I see is to use check some MFA token in various Cloud Code routines, such as beforeSave, beforeDelete, and beforeFind, denying access to an admin user lacking proper MFA. Would that completely prevent a false admin from reading or writing all data?
The above option does not prevent the attacker from trying to brute force the MFA (assuming it's a 6-digit code). I also don't see any way of rate-limiting the login attempts of an attacker with the App ID and admin password. Any ideas here?
Thanks for any tips!
I really like the idea of adding 2FA and a small script to manage user accounts on the dashboard.
Can you open a feature request on https://github.com/parse-community/parse-dashboard ?
Also, for use authentication, you could probably use a custom auth adapter which would validate the username, email and 2FA token
I understand the security issues around attempting to use OAuth for authentication from a provider's point of view. However I've been asked to provide users the facility to log on to a new web application using OAuth and obtain their basic identity info from the likes of Google and Twitter, from which a new user account within the client application will be created. Additionally users will be able to regster/login directly via user/passwords for anyone not wishing to use third party accounts.
We do not require any access to the user's details/info or providers APIs, just their basic identity when they first logon, and of course allow them to login via the provider in the future. Not exactly the use case OAuth is intended for, OpenId would have been preferred, but OAuth has been specified and without valid concerns would need to be adhered to.
My question is how safe is it to assume that the user has correctly authenticated themselves with the relevant provider. If I trust say Google to perform adequate authentication and I obtain an access token and their identity, presumably I can consider that a legitimate user? There are obviously issues if some one has access to the resource owners machine and saved passwords in the browser but that issue is present for those users who elect to register directly.
Presumably it possible to fake an access token, e.g. man in the middle pretending to be google? A MITM could fake an access token and supply identity details that matched a registered user's google id? I don't see anything for a client to know that the information definitely came from the provider. Obviously this problem is not unique to OAuth.
Are there another ways someone could illegitimately access an account that used OAuth to authenticate themselves.
OAuth allows that an application to access a specific user resource (that has been provided permission by the user) and it cannot go outside that scope. I have not seen the documentation that refers to creating a new user using OAuth based application.
That being said:
We do not require any access to the user's details/info or providers
APIs, just their basic identity when they first logon
This violates OAuth authorization process. The Service Provider does the authentication and provides the relevant tokens (based on the success of the authentication). This is to ensure that there are no 3rd party authentication done during the OAuth authentication process.
My question is how safe is it to assume that the user has correctly
authenticated themselves with the relevant provider.
This all depends on the service provider itself. To conform to OAuth protocol, one of the requirement is that user authentication must be done in a secured transport layer with a digital certificate (for HTTP, it must be done in HTTPS). OAuth consumer don't have any reference to the authentication process. Also the authentication process basically asks the user if the consumer can access the resource of the specific user (and not anyone else, since he doesn't have authorization to it).
Is it possible to fake an access token, e.g. man in the middle
pretending to be google?
Spoofing a Service Provider IS possible but it'll be tedious. For one, you will have to create a whole OAuth handshake process, create the exact API as the service provider, also setup an environment that is secured (as OAuth recommends). The only thing the spoofing service provider can obtain is the client credentials. If it has its user credentials, there is no need to use the application as there is no way of providing a user credentials using an application to do malicious damage.
Secondly, access tokens do expire so even if you spoof and retrieve an access token, the original application owner can ask for the service provider to block the application and the access token can be useless.
A man in the middle attack won't be possible. You will have to replicate the service provider in a sense that the end user won't be able to distinguish between the original and the spoofing service provider in order to capture all relevant credentials (from both the application and end user).
Sadly saying, the scenario from your last sentence is the truth.
But you should realise that the security is a huge and complex issue, especially in client side. It's not happen just in a single point but many points through the whole internet access life cycle. The scenario you given is not what OAuth try to solve.
I see these two terms bandied about quite a bit (specifically in web-based scenarios but I suppose it's not limited to that) and I was wondering whether or not there was a difference.
It appears to me that they both mean you're allowed to be doing what you're doing. So is this just a nomenclature thing, or is there a basic difference in meaning?
There is indeed a fundamental difference. Authentication is the mechanism whereby systems may securely identify their users. Authentication systems seek to provide answers to the questions:
Who is the user?
Is the user really who they claim / represent to be?
Authorization, by contrast, is the mechanism by which a system determines what level of access a particular (authenticated) user should have to resources controlled by the system. For an example that may or may not be related to a web-based scenario, a database management system might be designed so as to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the database, while giving other individuals the ability to change data. Authorization systems provide answers to the questions:
Is user X authorized to access resource R?
Is user X authorized to perform operation P?
Is user X authorized to perform operation P on resource R?
Steve Riley has written a quite good essay on why they must remain distinct.
Authentication refers to verifying an entity's identity. Authorization deals with what an authenticated entity is allowed to do (e.g. file permissions).
The main point is:
Authentication deals with user account validation. Is this a valid user? Is this user registered in our application?. e.g.: Login
Authorization deals with user access validation to certain feature. Does this user have the authorization/right to access this feature? e.g.: Claims, Roles
In my experience, Authentication usually refers to the more technical process, i.e. Authenticating a user (by checking login/password credentials, certificates etc), whereas Authorization is used more in the Business Logic of an application.
For example, in an application, a user might login and be authenticated, but not authorized to perform certain functions.
Authenticating a user on a website means that you verify that this user is a valid user, that is, verifying who the user is using username/password or certificates, etc. In common terms, is the person allowed to enter the building?
Authorization is the process of verifying if the user has rights/permission to access certain resources or sections of a website, for example, if its a CMS then is the user authorized to change content of the website. In terms of the office building scenario, is the user allowed to enter the networks room of the office.
If I can log-in, my credentials are verified and I am AUTHENTICATED. If I can perform a particular task I am AUTHORIZED to do so.
Authentication verifies who you are and Authorization verifies what you are authorized to do. For example, you are allowed to login into your Unix server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication........
Compared to the rest of the responses which try to explicitly specify the definition or technology. I'll submit an example can be more valuable.
Here's some an article that makes a great analogy to a passport versus a lock and key
When speaking about authentication (also called AuthN), think about identity. Authentication tries to answer “is this person who they say they are?” It’s a software equivalent of a passport or national ID check. Or to put it in more realistic terms, authentication is a similar process to that moment when you look at another person’s face to recognize that this is your friend from college and not your annoying second floor neighbor.
On the other hand, authorization (also called AuthZ) is all about permissions. Authorization answers a question “what is this person allowed to do in this space?” You can think of it as your house key or office badge. Can you open your front door? Can your annoying neighbor enter your apartment at will? And more, once in your apartment, who can use the toilet? Who can eat from your secret stash of cookies tucked away in your kitchen cupboard?
Authentication verifies who you are and Authorization verifies what you are authorized to do. For example, you are allowed to login into your Unix server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication.
Authentication: verifying who a user is.
To authenticate, the user provides credential information such as a username and password and if the credentials are valid, the user receives a token that can be sent in with future requests as verification of her authentication.
Authorization: determining what a user is allowed to do.
From the user’s perspective, a successful authorization takes place when she is able to send a request to access a system and do something (such as upload a file in the system) and it works.
Authentication only verifies identity—it confirms that a user is who she claims to be. Authorization determines which resources a verified user can access.
Authentication
Authentication verifies who you are. For example, you can login into your server using the ssh client, or access your email server using the POP3 and SMTP client.
Authorization
Authorization verifies what you are authorized to do. For example, you are allowed to login into your server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication.
Authorization is a process by which server determines if the client has permission to use a resources or access file.
Authentication is used by a server when the server needs to know exactly who is accessing their information or site.
Simple real time example, If student is coming to school then principal is checking Authentication and Authorization.
Authentication:
Check student ID card it mean He or She belong to our school or not.
Authorization:
Check student have permission to sit in Computer Programming Lab or not.
I have tried to create an image to explain this in the most simple words
1) Authentication means "Are you who you say you are?"
2) Authorization means "Should you be able to do what you are trying to do?".
This is also described in the image below.
Authentication:
It is the process of validating if an identity is true or false. In other words, verifying that a user is indeed the one he or she claims himself/herself to be.
Authentication types:
Username + password type of authentication
Authentication using social accounts
Passwordless authentication
Multifactor authentication
Fingerprint or retina based authentication etc
OpenID is an open standard for authentication.
Authorization
The technique that determines which resources are accessible to a user with a given identity or role.
OAuth is an open standard for authorization.
Authentication:
An application needs to know who is accessing the application. So authentication is related to word who. Application will check it by a login form. User will enter user name and password and these inputs will be validated by the application. Once the validation is successful, user is declared as authenticated.
Authorization is to check whether user can access the application or not or what user can access and what user can not access.
Source: Authentcation Vs Authorization
I was thinking about security for my REST web Service API, and decided to take a look at others large services and how they do it. As an example I decided to study Twitter's OAuth. After reading beginners guide I'm a little be confused and shocked.
As I understood it's Service provider responsibility to authenticate user and to show User what kind of access consumer is demanding (for example it want's read only access to specific resource). But I saw service providers that doesn't inform user on what type of access consumer is demanding (and even now showing consumer's identity). The second part of problem is that consumer can show his own custom Provider Service Authentication form in IFrame, and just hide access details, they can just steal you password, or request unlimited access to you resources, they can do basically what ever they want, there are lot's of way to trick user.
As an example let's take a LinkedIn. They request your gmail username and password inside their own form, and you have no idea how they will use it. They can just steal it and store in their DB, they can OAuth with it to gmail (and they don't show gmail's page with information what type of access they request), they can do whatever they want with this information.
What I'm trying to say is not that OAuth communication protocol is not secure, but rather there are lot's of way to use it improperly to trick the user and get his credentials.
BTW there were some security flaws in OAuth protocol itself: (http://oauth.net/advisories/2009-1/) and I'm pretty sure there are more, but no one cares to find them.
I'm going to go with 'You didn't understand it.' (In your defense, very few people do.)
Let's be clear: The session fixation attack you're referring to affected OAuth 1.0, but was resolved in OAuth 1.0a, which became RFC 5849. There are no major implementors of OAuth 1.0 — the major implementors all either implemented OAuth 1.0a/RFC 5849 or they implemented one of the OAuth 2.0 drafts.
As for the username/password anti-pattern, OAuth 1.0a does not provide for a mechanism to exchange a username and password for an access token. OAuth 2.0 does, but only for the purposes of supporting installed applications. Keep in mind that an installed application could simply keylog (or similar) if it really wanted to. When it comes to security, all bets are off if an application is already running natively and unsandboxed on the client's machine. But this is actually a very different scenario than what you're talking about. Web applications in both OAuth 1.0a and OAuth 2.0 don't ever touch the username and password.
The flow for OAuth 1.0a goes like this: The application asks the provider for a request token, telling it all of the things it wants access to. The provider issues the temporary unauthorized token, at which point the client may send the user to the provider to authorize that token. The user logins in with their username and password on the provider's site and then either grants or denies access. The provider then redirects back with a verifier string that allows the site to upgrade to an authorized access token. All of these interactions are signed. If the signatures don't match on any of them, the provider will reject the request. And the user can revoke any token at any time, removing the client's ability to access their account.
There are a number of security considerations with the protocol, but if you actually read the list, it's essentially the same list of the security issues that affect almost every site on the internet. These security considerations are all very well known and very well understood. To my knowledge, there are currently no known exploitable attacks against providers that correctly address all of these security considerations.
Point being, you are much safer using OAuth 1.0a or OAuth 2.0 to authorize a third party than with any of the alternatives. If you don't feel comfortable with these, the solution is simple: Don't authorize third parties to access your account. There certainly are plenty of reasons why you might not want to do that.
It sounds like you are confused about what's not secure. As I understand it, the OAuth protocol itself, if implemented properly, is secure. It's just that it's easy to implement improperly, and users get confused because they don't really understand what they are doing.
For example, what LinkedIn is doing is all wrong. I would never give them my gmail account information in this way. In order for me to provide my gmail account information, I insist on seeing that my browser is using SSL with Google and so the root frame of the page comes from Google.
Then there is the matter of trusting Google to correctly tell me what access is being requested and by who. If I don't trust them to do this, I shouldn't be using OAuth.