I'm making a twitter client, and I'm evaluating the various ways of protecting the user's login information.
IMPORTANT: I need to protect the user's data from other other applications. For example imagine what happens if a bot starts going around stealing Twhirl passwords or Hotmail/GMail/Yahoo/Paypal from applications that run on the user's desktop.
Clarification: I asked this before without the 'important' portion but stackoverflow's UI doesn't help with adding details later inside the Q/A conversation.
Hashing apparently doesn't do it
Obfuscating in a reversable way is like trying to hide behind my finger
Plain text sounds and propably is promiscuous
Requiring the user to type in his password every time would make the application tiresome
Any ideas ?
This is a catch-22. Either you make the user type in his password every time, or you store it insecurely (obfuscated, encrypted, whatever).
The way to fix this is for more operating systems to incorporate built-in password managers - like OS X's Keychain. That way you just store your password in the Keychain, the OS keeps it secure, and the user only has to type in 1 master password. Lots of applications (like Skype) on OS X use Keychain to do exactly what you are describing.
But since you are probably using Windows, I'd say just go with some obfuscation and encryption. I think you may be slightly paranoid about the password-stealing-bots; if your application doesn't have a large userbase, odds are pretty low that someone will target it and specifically try to steal the passwords. Besides that, they would also have to have access to their victim's filesystem. If that's the case, they probably have a virus/worm and have bigger problems.
I think you are missing the bigger picture here:
If the desktop is compromised, you're F#*%ED!
To steal a password from your program, a virus would have to be running on the system as administrator. If the virus has achieved that, stealing passwords from your program is way down on it's list of malicious things it wants to do.
Store it in plain text and let the user know.
That way, there are no misconceptions about what level of security you have achieved. If users start complaining, consider xor'ing a published-on-your-website constant onto it. If users keep complaining, "hide" the constant in your code and tell them it's bad security.
If users can't keep bad people out of the box, then in effect all secret data they have is known to Dr. Evil. Doesn't matter whether it's encrypted or not. And if they can keep evil people out, why worry about storing passwords in plain text?
I could be talking out my ass here, of course. Is there a study showing that storing passwords in plain text results in worse security than storing them obfuscated?
If you are making a twitter client then use their API
Twitter has very good documentation, so I advise you read it all before making a client. The most important part in relation to this question is that you don't need to store the passwords, store the OAuth token instead. You need to use the xAuth stage to get the OAuth token, then use other Twitter API's with this OAuth token where necessary.
xAuth provides a way for desktop and mobile applications to exchange a
username and password for an OAuth access token. Once the access token
is retrieved, xAuth-enabled developers should dispose of the login and
password corresponding to the user.
You never store passwords if you can get away with it
Using OAuth the worst that can happen is a 3rd party (black hat hacker) gets access to that Twitter account but not the password. This will protect users which naively use the same password for multiple on-line services.
Use a keychain of some sort
Finally I agree that pre-made solutions such as OSX's keychain should be used to store the sensitive OAuth information, a compromised machine would only reveal the information of the currently unlocked keychains. This means in a multi user system only the logged in users have their keychains become vulnerable.
Other damage limitations
There may be stuff that I've missed take a Google for "best security practices" and start reading for what may be relevant.
EDIT (in response to finnw desired general case solution)
You want, given no user input, access to an on-line service. This means typically you have, at most, user level access control to the authentication credentials via something like Keychain.
I have never used OSX Keychain so now I'll talk about SELinux. In SELinux you can also ensure these authentication credentials would only given to your program. And if we are continue going on OS level stuff, you could also sign all processes from boot to cryptographicly be certain no other program could be mimicking your program. This is all beyond a typical user system and given this level of setup you can be assured the user is not naive enough to be compromised, or a sysadmin is compitant enough. At this level we could protect those credentials.
Lets assume we don't go that far into protecting those credentials, then we can assume the system is compromised. At this point the authentication credentials become compromised, obfuscation/encryption of these credentials on the local side don't add any real security and neither does storing part or all of it on a 3rd party server. This is easy to see because given no user input, your program needs to bootstrap itself to obtain those credentials. If your program can do it with no input, then so can anyone who has reversed engineered your obfuscation/encryption/server protocol.
At this point it is damage limitation, don't store the password as authentication credentials. Use OAuth, cookie sessions, salted hashs, etc, they are all just tokens representing that at some point in the past you proved you knew the password. In any good system these tokens can be revoked, time expired and/or periodical exchanged for a new token during active session.
The token (whatever form it may be) can also contain additional non user input authentication information which restricts your ability to use them elsewhere. It could for example encapsulate your hostname and/or IP address. This makes it difficult to use the credentials on a different machines since mimicking these forms of credentials would require access to the appropriate level of network infrastructure.
Upon further contemplation I think I found a way. I will use ASP.net authentication for my application desktop application, store their credentials online and let Internet Explorer's password manager handle the local caching of this secondary pair or credentials for me.
I will just have to have them authenticate through a Facebook-API like form during the first login.
I don't get it... why is encryption no good? Use a large key and store the key in the machine key store (assuming Windows). Done, and done.
OSX: Use the Keychain
Windows: Use CryptProtectData and CryptUnprotectData
Linux: Use GNOME Keyring and KDE KWallet
Related
With OAuth 2.0 PKCE Flow for Installed App (e.g. a desktop app/cli/client library), it seems that nothing is preventing an attacker to:
obtain client_id by using the original app (client_id is public and can be easily copied from browser bar/source code)
make a fake app to mimic original app
use the fake app to seduce the user to grant access and thus obtain a refresh token which essentially means full access within requested scopes
Without PKCE, it's hard to fake an app and obtain a refresh token because that would require an attacker to obtain client_secret. It seems to me that, although PKCE offers security improvements over implicit flow, it makes it so much easier to masquerade authentic apps that use OAuth 2.0?
I'm using googlecloudsdk (gcloud), it seems that it has client_id (and even many client_id/client_secret pairs) hard coded into the source code, which is distributed to the client. I doubt there's anything to stop attackers to fake gcloud and thus gain access to user's GCP environment (for proof, run gcloud auth login and it will show you the url in the console that an attacker needs.) Could anyone clarify/help me to understand what's going on?
Private URI schemes are probably the best you can do on desktop but are not perfect as you say. It is what I use for my Desktop Code Sample, but ideally I'd also like to resolve the above concern.
For mobile you can use Claimed HTTPS Schemes to solve the problem - see the answer I added to the post sllopis sent.
I would be aware of Updated OAuth 2.1 Guidance for Native Apps - see section 10 - but I don't think you can fully solve this problem.
It is expected that end users are careful about desktop apps they install, to reduce risks for this scenario. Hopefully operating system support will enable better cryptographic options in future.
Just wanted to follow up on this because I had the same question myself, but also answered it myself and I wanted to add something that wasn't said here:
When you set up the application on the oauth2 server, you have to set up a number of redirect_uris, allowed places to return to after authorization is complete. This means that someone who creates a phishing attack like the one you described cannot return to their own app after login, and will never receive the code.
There is a separate attack where you try and return to a legitimate app from an illegitimate app, however this is solved by the inclusion of the state variable.
Are there any security best practices for using Rails and Heroku Postgres with pgcrypto's public key PGP.
The naive and direct way seems to be to store the private key and password using Heroku's ENV variables. However this seems like it doesn't add much security since both values are now easily accessed by anyone with access to the environment.
The goal of this would be to encrypt any privacy concerned information such as SIN numbers appropriately.
Scenario:
Let's presume you have some fields that, for some generic regulatory privacy requirement, are required or recommended to be stored encrypted, such as government IDs (SIN numbers for example). What is an appropriate or even common process for encrypting this information using pgcrypto.
If someone has an alternative suggestion for a scenario I'd be glad to include that as well.
This question doesn't have an answer until you define your threat model, but your question suggests that you want to store information in a way that even people with access to the server environment can't read it, in which case there are really only these options:
Don't store the data at all. Depending on what you need the data for you may be able to avoid storing it on your own servers for any reason. For instance, you can ask a user to enter their credit card number and immediately forward it to the credit card processor without saving it (which means you will need to ask them for the number again next time, unless the credit card processor hangs on to it for you.) Some payment processing schemes even send the payment data directly to the processor so that your website doesn't have to touch that data at all. Depending on your requirements this may or may not suit your needs.
Store the data only as a hash, like a password. This is useful if you don't actually need the data, but only need to verify that someone using your site has the data. This is universally the solution for passwords and other "secrets" but is useless for other data.
Store the data with public/private encryption, and don't keep the private key on the server at all. This could work if, for instance, the server has the public key in its environment, with which it saves data to the table, but an administrator has to download the encrypted data and decrypt it locally in order to use it. Again, this has severe limitations so you can only use it if your requirements of what to do with the data are compatible.
Store the data with client-side symmetric encryption, encrypted and decrypted only with a client key. This is how e.g. LastPass works. It means that you, the server admin, can not do anything with the data except return it to the user that submitted it. Once again, this only works if your requirements are very narrow.
If your requirements for what you do with the data are not compatible with any of the above, then you have no recourse. You could encrypt the data with symmetric encryption and keep the key in the server environment as a guard against backups or access to the database, but not the application, falling into the wrong hands, but that does not match the threat model of an attacker with access to the operating environment.
There is no one-size-fits-all "best practice" here because the tradeoffs involved in handling a threat model where the attacker has access to the environment are so great that only applications with very specific, limited requirements can guard against it at all. If the server can read the data, then so can an attacker.
Heroku Env
You get some benefit in storing the key in the Heroku env and encrypting in the database because then an attacker can't get the information from the DB either by direct break in or by SQL injection.
You are still vulnerable to anyone who can break into your app server, your Heroku account or any Heroku or Amazon staff that can obtain access to the server.
Separate Secure Server
If you have a large team and or subcontractors that can access your Heroku account you could have a separate server on a separate account or even separate more secure hosting that is reponsible for saving and loading the secrets with only a few highly trusted people having access to it. It could be kept small and simple and only accept requests from your app servers to minimise the attack surface. The server could be designed to limit the rate at which it provided the confidential data from the database to prevent a complete dump being taken rapidly even in the event that your main App server is broken into. It could access the same DB or a different on and perform the encryption/decryption on every load/save request from the app server before passing the result back.
Doing this will add latency and complexity but that is a trade off you can consider against the security gains. To get the secret information in bulk an attacker would have to either break into/have access to the app server and extract the secret data slowly from the secure server without triggering your intrusion detection systems or obtain direct access to your secure server in some way (which should be harder than the main server as there are less accounts to target for social engineering, password guessing and the direct attack surface area should be smaller.).
When using OAuth (2) I need a redirection endpoint in my application that the OAuth-offering service can redirect to, once I have been authenticated.
How do I handle this in a single page application? Of course, a redirect to the OAuth-offering service is not nice here, and it may not even be possible to redirect back.
I know that OAuth also supports a username / password based token generation. This works perfectly with an AJAX call, but requires my single page application to ask for a username and password.
How do you usually handle this?
Most of the time, a redirect is okay even for SPA because users don't like to put their X service credentials on any other website than X. An alternative will be to use an small popup window, you can check what Discourse does. IMHO a redirect is better than a popup.
Google Some providers support the resource owner flow which is what you described as sending username and password, but this is not nice. These are the problems I see:
Asking google credentials to users in your site will be a no-go for some users.
The resource owner flows need the client_secret too and this is something that you must NOT put in your client side javascript. If you instantiate the resource owner flow from your server-side application and your application is not in the same geographically region than the user, the user will get a warning "hey someone is trying to access with your credentials from India".
OAuth describes a client-side flow called implicit flow. Using this flow you don't need any interaction in your server-side and you don't need the client_secret. The OAuth provider redirects to your application with a "#access_token=xx". It is called implicit because you don't need to exchange authorization code per access token, you get an access_token directly.
Google implement the implicit flow, check: Using OAuth2 for Client-Side apps.
If you want to use the implicit flow with some provider that doesn't support it like Github, you can use an authentication broker like Auth0.
disclaimer: I work for Auth0.
What José F. Romaniello said is correct. However, your question is broad and thus I feel any offered conclusions are just generalities at this point.
Application state
For example, without knowing how complex your application state is at the time you want to let your users log in, nobody can know for sure if using a redirection is even practical at all. Consider that you might be willing to let the user log in very late in his workflow/application usage, at a point where your application holds state that you really don't want to serialize and save for no good reason. Let alone write code to rebuild it.
Note: You will see plenty of advice to simply ignore this on the web. This is because many people store most of the state of their application in server-side session storage and very little on their (thin) client. Sometimes by mistake, sometimes it really makes sense -- be sure it does for you if you choose to ignore it. If you're developing a thick client, it usually doesn't.
Popup dialogs
I realize that popups have a bad rep on the web because of all their misuses, but one has to consider good uses. In this case, they serve exactly the same purposes as trusted dialogs in other types of systems (think Windows UAC, fd.o polkit, etc). These interfaces all make themselves recognizable and use their underlying platform's features to make sure that they can't be spoofed and that input nor display can't be intercepted by the unprivileged application. The exact parallel is that the browser chrome and particularly the certificate padlock can't be spoofed, and that the single-origin policy prevents the application from accessing the popup's DOM. Interaction between the dialog (popup) and the application can happen using cross-document messaging or other techniques.
This is probably the optimal way, at least until the browsers somehow standardize privilege authorization, if they ever do. Even then, authorization processes for certain resource providers may not fit standardized practices, so flexible custom dialogs as we see today may just be necessary.
Same-window transitions
With this in mind, it's true that the aesthetics behind a popup are subjective. In the future, browsers might provide APIs to allow a document to be loaded on an existing window without unloading the existing document, then allow the new document to unload and restore the previous document. Whether the "hidden" application keeps running or is frozen (akin to how virtualization technologies can freeze processes) is another debate. This would allow the same procedure than what you get with popups. There is no proposal to do this that I know of.
Note: You can simulate this by somehow making all your application state easily serializable, and having a procedure that stores and restores it in/from local storage (or a remote server). You can then use old-school redirections. As implied in the beginning though, this is potentially very intrusive to the application code.
Tabs
Yet another alternative of course is to open a new tab instead, communicate with it exactly like you would a popup, then close it the same way.
On taking user credentials from the unprivileged application
Of course it can only work if your users trust you enough not to send the credentials to your server (or anywhere they don't want them to end up). If you open-source your code and do deterministic builds/minimization, it's theoretically possible for users to audit or have someone audit the code, then automatically verify that you didn't tamper with the runtime version -- thus gaining their trust. Tooling to do this on the web is nonexistent AFAIK.
That being said, sometimes you want to use OAuth with an identity provider under you control/authority/brand. In this case, this whole discussion is moot -- the user trusts you already.
Conclusion
In the end, it comes down to (1) how thick your client is, and (2) what you want the UX to be like.
OAuth2 has 4 flows a.k.a. grant types, each serving a specific purpose:
Authorization Code (the one you alluded to, which requires redirection)
Implicit
Client Credential
Resource Owner Password Credential
The short answer is: use Implicit flow.
Why? Choosing a flow or grant type relies on whether any part of your code can remain private, thus is capable of storing a secret key. If so, you can choose the most secure OAuth2 flow - Authorization Code, otherwise you will need to compromise on a less secure OAuth2 flow. e.g., for single-page application (SPA) that will be Implicit flow.
Client Credential flow only works if the web service and the user are the same entity, i.e., the web service serves only that specific user, while Resource Owner Password Credential flow is least secure and used as last resort since the user is required to give her social login credentials to the service.
To fully understand the difference between recommended Implicit flow and Authorization Code flow (the one that you alluded to and requires redirection), take a look at the flow side-by-side:
This diagram was taken from: https://blog.oauth.io/introduction-oauth2-flow-diagrams/
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/
I'm coding a desktop application for our university . Users need to signup before using this software and registration request is sent to a server written by me, too. So I'm struggling with kind of network application. ( Suppose that the request format is as simple as a HTTP request sent to an arbitrary port number )
But now I'm wondering whether it's necessary to protect registration process using CAPTCHA or not? Do I need to ensure that the signup request is not generated by a computer?
As your application is for a limited user group (your university only), I think you do not need a captcha, because the risk is very low that someone is in this group how wants to annoy you.
Also scripting for a desktop application is (a bit) more complicated than for web applications, this will decrease the risk, too. IF you are struggling with bot-registrations you could still ship the captcha as an update and only accept registrations from the updated version, don't you?
I think that would irritate the human users, who, I believe, would make all your users. Please note that on the net, only a small portion of users are bots. What about a campus? How many computers are on a campus to be worry about? Besides, all those computers are supervised by people you know, and even if a program is installed on one of them (or even all of them) to joke with you, you can call the authorities of the university. So if I were you, I would put my time on betterment of other things, instead.
No you don't need CAPTCHA. CAPTCHA was made because of the limitations imposed by a web browser while still wanting the wide availability that a website provides. Your application doesn't have either of these limitations. Your desktop application can implement whatever security methods it wants and it only needs to be distributed to a specific set of clients.
That doesn't mean you shouldn't have some security policies set up to prevent anyone on the school campus (or internet) from telneting to the port and creating an account. This can most easily be done by using PKI and distributing a unique private key and open public key with the desktop application. The server can then verify that the client has the private key before accepting registrations (plus you could encrypt any communications between the client/server). Of course anyone with access to the desktop application could get the private key, but it's at least more secure than not doing anything at all to prove they can register accounts.