There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.
Related
In case of using password-backed authentication, if user forgets the password, the provider always trusts the user's email security.
So why the whole fuss? Why not use email for sending the secret login keys to registered users? Isn't that what sites do when user forgets the password?
What is the reason for still using passwords for authentication?
What are the major problems with passwordless auth that passworded auth lacks?
One difference is if you log on via forgotten password, you usually have to change the password to something else, so it cannot be undetected - an attacker will likely be discovered. If it's just a login link in email, this is not the case, the attacker can log in, and likely nobody will notice. There can be controls to mitigate this of course, but it quickly becomes a UX question.
Another UX aspect is having to go to your email all the time if there is only a login link. A lot of people use password managers, which make entering very secure and unique passwords really easy. If it's a login link, you have to open your email, disrupting your flow in the application. It's arguably inconvenient.
Also a login link sent in an email will contain a token in the url. That will be remembered by the browser, logged in intermediate proxies, logged to the web server logs and so on. Secrets should not be sent in the url. However, if it's a one-time token valid for a (very) limited time, this risk is very much mitigated.
Having said all these, there are commercial applications that opted for passwordless login via an emailed link. If implemented correctly (a strong enough one-time token with enough entropy, generated with a proper crypto random generator and so on), passwordless login via an emailed link can be secure enough for many applications, and it's mostly a UX question (keeping in mind the security considerations above).
I'd like to know if its worth investing time into developing an IdentityServer3 implementation that would work similarly to how Sharepoint allows for an initial Login using Integrated Windows Authentication, but then allow user to login as a different user with a prompt for credentials. Our hospital has many users where their primary workstation is set up as generic login. I'd like to use integrated Authentication, but allow these users on generic workstations to re-login as themselves.
From my research I think a logout page that actually invalidates the original token along with a secondary external Identity provider running without integrated Authentication is where I'm heading, but would like some validation that its feasible.
You would approach that problem differently with IdentityServer - on the login page you would give the user a choice. Either use integrated authentication or specify some username/password explicitly.
Logging out of identityserver would then also allow to switch identity if needed.
So yes this is possible.
We have an example that does built-in Windows authN (username/password is disabled - but you can re-enable by setting EnableLocalLogin to true here https://github.com/IdentityServer/IdentityServer3.Samples/blob/master/source/WebHost%20(Windows%20Auth%20All-in-One)/WebHost/Startup.cs#L36).
Few sites I've come across using either Google, Facebook or Twitter connect for login. Still they are asking for new password creation.
Ex: http://setapp.me/
Why user need to setup another password when the user is using OpenID/Facebook/Twitter connect?
One need I can think of: if the user disconnects the app from any of the above OAuth/OpenId connect services providers (Google/FB/Twitter/...), then as an alternative way for the user to login - as a best practice.
What they're doing is an incremental step towards federation, but not what I'd describe as a best practice. For apps that aren't ready to fully embrace relying on another service for identity it is still sometimes helpful to connect with identity providers to speed up the sign-up process. In other words, just as a mechanism for pre-populating the signup form.
However, if using it for sign-on, then having a local password is one more potential vulnerability. The reality is the vast majority of users just re-use passwords across sites. That password is only as secure as the weakest application that stores it. If one app is compromised and email & passwords recovered, attackers know that a good percentage of those are valid logins elsewhere.
Best thing to do when federating with Google/Facebook/etc is to not ask the user for their password at all. Trust the major identity providers to keep account information & credentials secure rather than take on that responsibility yourself and deal with the fallout if your app is compromised.
Lots of good reading here if you're up for it: https://docs.google.com/a/google.com/document/pub?id=1O7jyQLb7dW6EnJrFsWZDyh0Yq0aFJU5UJ4i5QzYlTjU#h.moajj1qnb85l
I am in the process of scoping out whats involved in setting up single sign on using SAML and ADFS. A query has come back that I can't answer and can't seem to find anywhere.
Is it possible to carry out the usual user profile actions via ADFS? For example :
Can I register new users via ADFS?
Can I provide forgotten password / reset password functionality via ADFS?
I'm getting confused and have a feeling I am barking up the wrong tree!
No, AD FS only delivers security tokens for Active Directory accounts, after providing some form of credentials for such an account. It does not make any kind of changes in Active Directory, nor anywhere else.
No, AD FS has no 'reset password' functionality. However, the AD FS sign-in pages can be customized, and the functionality to change the (AD) password can be added by customizing/creating the appropriate ASP.NET pages. Been there, done that. Unfortunately I cannot share that code.
(This answer applies to AD FS 2.0 only; I'm not sure about AD FS 1.0.)
#Marnix is correct - ADFS is an "Access Manager" not an "Identity Manager".
As you can customise pages, there is nothing stopping you creating provisioning pages or adding links to a provisioning system.
Word to the wise: The "standard" ASP.NET membership pages provision to a SQL DB which won't help you. ADFS authenticates against AD only. You need to use AD membership.
Also, for internal users who login to their desktop with WIA and SSO behind the scenes with ADFS, you get the standard password functionality e.g. password about to expire, change password etc.
In addition to that: Microsoft has another product which integrates with ADFS (and other auth mechanisms) called Forefront Identity Manager which provides password reset / user self management as well as account creation via delegated fine granted rights. All that using a web-interface.
i guess that is what you're looking for.
However: adfs itself is only a tool to provide federation and SSO - so it's there for authentication / delegation, not mangement.
I am working on iPhone application which have login form to access application functionality same as website. now i want to add one button in iphone application that redirects user in to website in safari browser with successfully login.
After success login in to iPhone application, user want to check website in browser so i just need to add functionality that user can directly login in his account and redirect on particular page.
i have some basic idea for that we can do with encrypted username and password with url.
like http://xyz.com/login/username=abc&password=abc
but i know that its not secure way to pass username and password with url.
So please suggest me any other way if possible.
Any idea or alternative that how to implement this.
Thanks in advance.
There are a few ways to do it.
Any time you send password information over the Internet you want it to be encrypted over SSL. This will require an SSL Certificate for your web server though and it's not always possible.
You can also encrypt the username and password yourself in a way that only your web server will know how to decrypt. So the username "foo" could be turned into "oof" and the password "bar" could be turned into "rab". That way if someone intercepted your requests, they couldn't know what the username and password were without knowing how you changed them.
Why not pass the session id?
Here's what I mean: When you log in to a web site, typically you're assigned (or already have) a "session cookie" which essentially tells the server "This visitor has session ID 'XYZ'", and allows it to retrieve the server side information stored for that user (like who they are, that they authenticated, or whatever else you store in the session store.
One of the easier ways of moving to/from applications is to make sure that all logins generate a server side session, and provide a script which will overwrite the user's session cookie and redirect them to the proper page.
session_restore.php?sessionId=12345&redirect=HOME
The doubters here will argue that providing such a script is tenement to a security breach, but I would argue that all of this information is stored client side already, and can be accomplished without the server's intervention anyway. (session hijacking plugins for popular web sites exist for firefox that will grab session IDs from wireless networks - no technical skill needed)
Doing it this way just makes the process friendlier to the user, and if your site provides SSH access (which you really should be doing anyway) then the risk is very minimal.