... without causing major UX problems?
While I'd like to think my subscribers wouldn't share their account log on details since it's keyed off their email address, I suppose it's so easy to get throw away email addresses these days there's a good chance it could happen.
Are there any common, effective methods to prevent subscription membership account sharing? My app is in C# on ASP.NET MVC, if there are some examples on that platform I'd like to see them.
use Single Signon using an OAuth2 provided who does a descent job of preventing duplicate accounts. Facebook,github etc. can be good choices, but depends on your use case.
A biometric ID would be extremely UX friendly, and will ensure non-sharing of accounts. iPhone 5S has taken the initiative. It may become a common option in next couple of years.
Related
The title pretty much says it all. I am currently implementing two factor authentication and wonder whether I should provide a list of recovery codes. I wouldn't even have thought of it myself, but most implementations I have seen in the wild do it this way. Github for example generates a list of 16 recovery codes at once.
Is there any security benefit?
Great question - I'm pretty sure it's an ease of implementation thing for both parties - if you generate a list of recovery codes up front then you don't have to regenerate a code every time a user uses a backup code. The idea is that the user will print/save them somewhere so from a usability perspective this saves the user from having to re-print or re-save codes.
You don't have to use recovery codes, though. GitHub supports a few different recovery options. Some companies use security questions or allow you to fall back to SMS.
Some companies make you call support and provide account details (works for enterprise use cases where there's a trusted contact/if you expect to have a small number of account recovery cases/have a good way of verifying identity over the phone [disclaimer I wrote that post for Twilio]).
Facebook lets you choose friends to vouch for your identity if you get locked out.
I gave a talk about this last year and have some more recommendations in the slides. Hope this helps!
Our users create orders via an external online platform. This online platform sends our API any orders created by our users. How can we safely ensure that these orders were created by the user the online platform says?
We are investigating sending an authentication challenge for each order received via email/sms. This could become tiresome for operators creating orders all day though. What is the ideal pattern?
Security, including non-repudiation concerns, is a question of striking a balance between safety and convenience. The more secure you make a system, the more inconvenient it becomes, and vice versa.
A sufficiently secure system could be so inconvenient that it scares away users. Thus, security analysis and threat modelling should involve both technical and business stakeholders. Making a maximally secure system that no-one wants to use solves no problems if your company goes out of business from lack of customers.
The OP concern about order verification via email or SMS is a good example of this conundrum.
Specifically regarding order verification, you might consider a 'batching' feature where super users can create batches of orders that they only have to verify with a single SMS or email.
The disadvantage of that idea is that you run the risk of users misunderstanding how the feature works. If it's unclear to users that they have to submit the batch at the end of the working day, they may believe that they've submitted many orders, where in fact, they've submitted none.
This strikes me as mostly a UX problem, more than a technical problem.
Another option is to ask each user to sign their orders using PKI. Users should sign with their private key, but this again becomes a usability and infrastructure challenge.
Work with all stakeholders to find an acceptable solution that solves the right problems.
Stack Overflow is obviously a great example of really successfull implementation of OpenID, but let's be honest - it's a little easier when your target user base is geeks like us! I'm really interested to hear people's experiences of implementing OpenID outside hi-tech websites.
What kind of responses have you got from
a) users?
b) statistics?
with regards to the user experience of OpenID 'login with..' login systems?
With a universe of undergraduate university students, I had a positive experience. OpenID was required for them to register in an event. Beware the sample was small (around 150 persons) and of a narrow scope (undergraduates). Also note that OpenID was required, so they maybe they were willing to spend some extra effort.
Login with is essential and you need to add a small set of instructions, telling them to click a provider or to enter an OpenID address, and that they may have to register e.g. with myOpenId. Except for an audience of programmers, virtually no one is going to enter an address of his own the first time (some tried to enter their e-mail or their name, but then they eventually got it -- maybe they read the text). After registering with myOpenID, one or two entered their claimed identifier directly.
I showed only three possibilities: Gmail, Yahoo and myOpenID. For myOpenID, I used IDENTIFIER_SELECT (I didn't tell them to enter their username and use that to build the URL, like SO does). Around 80% used their gmail account, Yahoo accounts comprised little above 5% and the rest registered with myOpenID.
I only got two support e-mails where the users had made logins with two different identifiers and therefore weren't being associated with their previous login. The first case was a bug in the normalization phase of my OpenID implementation (a problem with trailing spaces). The second one was caused by the mandatory (per the spec) distinction between http://www.example.com/path and https://www.example.com/path. I think one should consider to disregard that part of the spec.
In my experience, the use of OpenID by your average home user is low to non-existent. I guess they are either uninformed about the existence, or scared to use it. On a local news site, where commenting can be done by logging in with OpenID, statistics show less than 1% usage. Most of these users have no problem logging in with their (social site of choice) credentials, which they also support. Use of these types of login are very common.
In my experience, I notice a difference more with age-groups, than with techie/non-techie status. I guess you could look at that in general terms of younger folks being more "techie" than older folks, but I wouldn't go so far as to call them "high-tech" -- they're just more comfortable with computers/internet because it's always been part of their lives.
The younger my customers are, the less concerned they seem to be with privacy / sharing their information with a "service" on the web, be it OpenID, Google, Facebook, or what have you. They also don't seem to mind having 2, 3 or even more email accounts with different providers.
The older my customers are, the less comfortable they become putting their info online (e.g.: even the bare minimum required to get an OpenID). There are enough horror stories in the news about privacy-related issues -- be it advertisers, hackers, or government subpoenas getting a hold of their information, etc. It isn't that they know something bad will happen -- it's that they know they have no idea how to spot a fraudulent service, evaluate risks or protect themselves -- it all seems so complicated, so they make the conservative choice not to put their information "out there" at all. Some of my older customers will give it a go, but even then, I also see a lot of reluctance in this group to setup more than one email account -- they use the one that their ISP provides, and won't use anything else.
Anyway -- those comments are just about who is more or less willing to use something like OpenID. Of those who are willing (of my users, I'd say about 85% below age 40 will use it; I can count on about 60-70% of my working-adult customers in general to use it; And my retiree users are at about 20%). I have only a few complaints in the "willing" groups about usability.
OpenID can be implemented on the client site in different ways and that affects how likely it is to be used on any given site.
I think StackOverflow does a very good job and you just click on your provider and it redirects and you can authenticate. I've seen other sites that just give you a text input that say "OpenID" and it's not clear what they want you to type in; not nearly as easy to use. Zendesk is one example:
https://support.zendesk.com/access/unauthenticated?return_to=https%3A%2F%2Fsupport.zendesk.com%2Flogin
I'd say that the rising popularity of Facebook as a single login is going to drastically change how people feel about logging in using OpenID, provided you make the process entirely invisible. Look at the login page for FriendFeed, for example, which promotes "one click" joining/logging in. They actually appear to be using a combo of OpenID and OAuth but the user experience is largely the same.
Now that Facebook uses OAuth, it's fairly simple to login via Twitter, Facebook, or any OpenID provider by simple implementing login for OpenID and OAuth. I actually would recommend against implementing OpenID alone as it's not much more difficult to add-on OAuth and once added provides you with the BIG THREE: Facebook, Twitter, and Google along with Yahoo, MySpace, and all the other OpenID providers that are out there.
I have a webapp that requires security beyond that of a normal web application. When any user visits the domain name, they are presented with two text fields, a username field, and a password field. If they enter a valid user/pass, they get access to the web application. Standard stuff.
However, I'm looking for additional security beyond this standard setup. Ideally it would be a software solution, but I'm also open for hardware solution as well (hardware=key fobs), or even procedural changes (one time use passwords on a password pad for example).
The webapp is unique in that we know all our users ahead of time, and we create their username and password and give it to them. In this sense, we can be assured that the username and password are "strong".
However, our clients have requested additional security beyond this. Anyone have any ideas on how to add another layer of complexity to the security?
Our company used PhoneFactor and we absolutely love it.
We've also used Safeword Tokens in the past.
However, it's notthe only game in the book. I'd start by googling "Two factor authentication"
The OWASP guide to authentication is another good place to start. Actually, OWASP is the first place I'd look for ANY web security question.
Another option for additional security is to use a piece of physical 'evidence' such as a Smart Card: Protect Your Data Via Managed Code And The Windows Vista Smart Card APIs
There are lots of different areas that web apps can have their security improved on. Before getting started you need to determine what, exactly, your problem areas might be and what you want to focus on.
You might start this process by having a third party do Penetration Testing (PEN Testing) on your application. This should give a quick hit list of things you can take care of and, when you have a passing grade, is something to use in your sales literature.
Next you'll want to talk to your customers to understand what they mean by "more secure". Is it simply two factor authentication like David and Mitch mentioned or are they more concerned about things such as data in motion (ARP Poisoning, SSL, and the like), data at rest (everything from hard drive encryption to database encryption), authorization, impersonation (cross site and replay), personnel (ongoing background checks on who has access to the machines), etc..
The concept of security covers a lot of ground.
We've talked about personal password management here but how do you guys manage your passwords at a company wide level?
I thought I'd report back after my week of searching...
I've settled on PassPack I've been using it for a few days now for my personal passwords and I'm a total fanboy.
They use the Host-Proof Hosting pattern so the only one that can access your stuff is you and if you forget your password they can't help you.
They have some nice Offline apps written with Adobe AIR and Google Gears.
But, best of all, they fit my "enterprise" requirement because an upcoming release will support sharing within a trusted group.
Plus, I learned about The "Blog" of "Unnecessary" Quotation Marks in their forum.
We have managed to plan our company applications so they are mainly web based and open source or in-house developed. This then allowed us to use LDAP to hook into active directory for logging into our intranet. From there we modified the logins into various products we use (MediaWiki, Wordpress, SugarCRM etc.) so that if the user is authenticated in the intranet, they are automatically logged into these other products as well.
This has taken some time setting up the process and creating a script to set all the appropriate user details in each system when someone joins the company, however now we have a situation where everyone only has to remember one password, removing the need for managing a growing list of passwords.
Obviously this may not be viable in many companies, but now that we have it setup it was worth the effort.
We use Password Agent: http://www.moonsoftware.com/pwagent.asp
It stores everything from PC admin logins to website logins and product keys for products we all use.
We use Active Directory to store user credentials, and developed custom library for Desktop and Web
We are using KeePass application with success.
We create file per project and/or per business domain.
We share the password to appropriate KeePass file between people who should have access.
It's not the best solution. We also have Cyber-Ark software installed corporate-wide, but due to some strange configuration rules it does not work for us as good as the previous solution. It might be also related to the fact that we have an old version.
We maintain an in-house Lotus Notes database that stores absolutely everything from passwords to server change records. It is big, cumbersome, takes an age to load, and is generally not, uh, nice.
No, this is not a sane way to do it. :-|
Obviously I'm biased because I work there, but we use Enterprise Random Password Manager from Lieberman Software. Yes, we do actually dogfood our own tool in our own network. It has some nice features, like web accessibility with delegation, scheduled operation with retry, propagation to other things using accounts (services, COM+ apps, etc.), system/account discovery, Linux/Unix account management, etc.
I'm sure a salesperson could give a better pitch, but that I am not. I'd encourage you to check it out. :)
For passwords related to my work, I store them in a plain unencrypted passwords.txt file in my user storage area on the main company file server. Normally, other people in the company can't read files in my user storage area, so there is little risk of exposure. However, if something were to happen to me, then all my passwords for company related activities would be trivially available to others inside the company - just ask MIS.
This is a very different security model than what I use for my personal passwords, of course.
Just a heads up: Microsoft have a product managing credentials/passwords/identity across varied systems: Identity Lifecycle Manager
Secret Server is something that grew from an internal need (within our software company) to a viable product that is now used all over the world. It is web-based and allows you to store passwords and then securely share them with other users and groups (even AD users and groups). It is also able to actively reach out and change passwords on automatic schedules, even handling associated dependencies such as Windows Services for service accounts.
Enterprise Password Management (free 30 day trial).
Use Apache Directory Server, which is an LDAP-standard implementation.
You can manage the directory database using Apache Directory Studio so it's quite user friendly (or at least, admin-friendly).
Then you can hook the directory programmatically to any application that requires access to the credentials, LDAP client libraries are widely available on popular programming platforms such as Java, C++, PHP, Ruby, etc.
My business friend adviced me to check out Passwork (https://passwork.me). They use self-hosted version on own servers, i found out that Passwork also has SaaS.
So i and my colleagues store our company passwords in Passwork.
We had tried another enterprise pw managers before but weren't able to trust them.
We had a look at a product that had these features:
Can give access privleges to password using roles.
Handles delegation.
Logs access to passwords.
Can Randomize passwords.
Can automatically re-randomize a password X days after access to it.
Unfortunately, I can't couldn't it's name when I posted this... It was "Secret Server"