I'm thinking about adding another layer of security in my application.
Two factor authentication (2FA) seems like something I want to work with.
I want to know what determines a good 2FA? Also which ones would you recommend? I am currently not on Devise, so any independent third-party/gem would help.
What determines a good 2FA method? I'd say coverage (# of users that can use it), costs, and extra security benefits.
In terms of security, U2F is the best type of 2FA as it prevents phishing as well as MITM, though your users would need to purchase (inexpensive) tokens. Currently works only in Chrome.
Cheapest is Google Authenticator-style TOTP, which is free and does not incur any SMS fees. Your users need smartphones.
Highest coverage is SMS, which almost all users will have but you may have to pay fees to send SMS and your users may have to pay to receive them.
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I'm working for a non-profit that is trying to create a collection of services that will allow them to do a few things:
Create/Manage Users
Create/Manger Competitions
Create/Manager Events(a Competition is made up of many Events)
Logistics
Etc.
Here are some of the requirements:
Host on Azure
Accounts are created using the user's own email address (can be any domain)
Each service must be independent of each other
System should be accessible from anywhere(browser, mobile app, etc.)
Once a user logs in, access to other systems should be available(if needed or depending on permissions)
-services can talk to each other(we've successfully done a POC on this using Azure Active Directory)
I've spent some time researching the possible ways to tackle this, including looking at articles like this:
http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
It sounds like JWT is the way to go, but I want to make sure that this architecture approach lends itself to flexibility down the road. I'm willing to learn/user any technology as long as it plays along .Net, Web Api, and MVC.
My initial idea was to set each "system" as a Web API, which is pretty straightforward. My concern is authentication/authorization. The million dollar question then becomes:
How can I authenticate a user on a browser/mobile/desktop app and then make use of the other services(APIs), where each service can verify if the user is authenticated independent of other services.
For example, lets say I am using the web app(browser) and register as a user(using User service) in order to register for a competition(Competition service). what kind of technologies/architecture would need to be used for both services to use the same authentication mechanism?
I am not new to MVC or Web API but I am to a scenario like this, so all help or advice is greatly appreciate it. For any that are interested, this is the non-profit: http://worldjumprope.org/
They are doing some cool stuff in terms of outreach and spreading the love for jump rope. Their goal is to be able to help people all around the world and provide a way to for them to come together and compete. They've been doing it for years, growing each year, all for free and out of pure passion for the sport. Help me help them!
Azure Active Directory can help you with your need.
About the security/Auth mechanism, simply put, it is like you get a token from Azure Active Directory to be able to use it to do authentication for a certain Audiences/Tenants.
And in your architecture, when you acquire a Token, you can specify if you are going to use it against a certain audience or it will work for a list of audiences or all audiences in a specific tenant or in a multi tenant scenario.
Here is a link to a video about AAD Single Sign on:
https://azure.microsoft.com/en-us/documentation/videos/overview-of-single-sign-on/
You can download the AAD Solutions arcutecture from here:
http://www.microsoft.com/en-us/download/details.aspx?id=45909
Also maybe worth looking at Identity Server - https://github.com/IdentityServer/IdentityServer3.
Same concept as Azure AD in terms of tokens, but perhaps with greater options for what you choose as a data store for your user information.
There are lots of demos and source code on the site, particularly around the different types of authentication flow \ service to service authentication
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.
A client needs to send out eNewsletters.
We tried using their Sitefinity CMS, but it hangs for reasons that are hard to determine.
As a result, I am inclined to "roll my own".
However, various pitfalls yawn deep and dark along the imagined path.
For example:
Imagined Pitfalls
My client's domain gets blacklisted.
The emails get rejected as Spam.
Presumed ways of avoiding imagined pitfalls:
a. Send out emails with a delay of, say, 2 seconds between each one.
b. Send out emails individually, ie, no CC or BB.
Questions:
Are my imagined pitfalls and presumed
ways of avoiding them correct?
Can you think of other pitfalls?
Or better ways of avoiding them?
Do you know of reliable software that
just does this (ASP.NET, MVC by
preference, drawing form SQL Server
db).
It may be beneficial to use a third party like Constant Contact to handle sending your email campaigns. They expose an API that you can tap into via REST and it won't have any effect on your client's domain. Constant Contact is a reputable company and email campaigns they send out rarely get caught in Spam filters. My company currently uses the service, but not the API and its been very successful.
Constant Contact's Website
CC's API Web Site
Example of creating a Campaign
You should never do this. Your client's IP(s) and domain(s) will find themselves blacklisted to the point that even their legitimate, hand-crafted emails won't make it past spam filters at large mail services.
Use something like SendGrid if you want to stay closer to the metal than a service like MailChimp or Constant Contact.
There are other companies out there which do it, such as BriefYourMarket ... never roll your own :-)
I'm working on a small Rails application in which I'd like users to be able to prove that accounts they have at other sites, Live Journal, Stack Overflow, Reddit, etc. are in fact theirs.
Can anyone provide any guidance on how best to accomplish something like this?
I've outlined some potential options for account verification.
Ask users to basically pass their log in credentials to the application via SSL and allow it to verify that it can log in. Then, of course, log out and delete any user session data/credentials. Problems:
People are not going to psyched about the idea of exposing their credentials to a third party system.
Handing off log in information may well be against many
website's ToS agreements.
The idea makes me queasy.
Provide the user with a hash and ask them to insert it into some field of the their public profile. Putting "aTWIUqHRgxEpSVaQzCYc" in the location field of my Stack Overflow account for example and then having the application verify the hash via either API or screen scrape depending on the website.Problems:
This is tedious to do for more than one or two websites.
Some sites don't have any sort fields with user supplied information. Reddit for example.
Again, provide the user with a hash but ask them to send that hash via the website's message system to a specified user account. A server process would routinely check that account's inbox and then link the hash with the account. This seems like the easiest solution.
3B. Have the user friend the specified account when applicable.
I've not yet done enough due diligence investigating what options OAuth or OpenId might provide to speak intelligently about them.
I realize the headache of having to verify accounts this way is going to cause a barrier to entry. Not only that but failing to have a single consistent method for doing it.
I would go with OAuth / OpenID, there is a gem called omniauth and it supports a wide variety of external providers. Ryan Bates has made 3 railscasts about omniauth so you could start there! It's really easy to get it up and running. If you follow the railscasts by Ryan Bates you can allow your users to use more than 1 provider (e.g twitter, openid and facebook).