I'm designing a web-based app that will have its own authorization system (via Codeigniter-based Ion Auth) and will also be logging into a service in the background via API calls (Adobe Connect webinar services). When the user creates their account on the base system, it will simultaneously create an account on the Adobe Connect system, using the user name and password they enter. Easy enough to do.
The problem comes when making API calls to their account. During initial sign-up, the Ion Auth code translates the user's password into a salted hash value but this won't work for the API calls, which require their in-the-clear password for authorization. It wouldn't be an issue except that the user will also need to log into the Adobe Connect system directly for some functions.
My first thought is to create a field in the user's profile that stores their password in encrypted form, then decrypt it before passing to Adobe Connect. Does anyone have a better method to suggest?
Thanks in advance,
Mark
Related
I am developing a web application that uses Microsoft accounts to sign in. How can I safely and reliably grant external users access to this application by email address without requiring that I train users on Azure administration or have to implement some approval mechanism via API?
I believe that it is dangerous to use the ClaimsPrincipal.Identity.Name, which returns an email address. It uses the "preferred_username" claim behind the scenes, which along with the "email" claim are documented to not be a safe and reliable way to identify a user, so I assume that's user configurable and thus can be spoofed by a creative user.
It seems like if the user knows the email address or account name that they use to sign into their Microsoft account, that should be enough to authorize that user to access the application without requiring that they go through an additional step of verifying an email which I trust they use to sign in, but I can't seem to find a way to do this.
Here is the process of creating and granting the external users access to the application:
Please go this document for more details:https://learn.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0&tabs=http
Hope this helps.
I have the following mobile app scenario based on a Firebase backend:
Two or more mobile app instances communicate with each other through a central service (trusted). The apps are paired by exchanging a shared secret, e.g. through scanning a QR code or entering a pairing code.
Users are anonymous, ie no signup required (or possible). Essentially, it is the specific app on a specific device that is paired with a ditto counterpart (vs user-to-user).
Information exchanged is sensitive but has no intrinsic value: It must be possible to trust that information comes from a given device and it must be possible to trust that the information has reached the intended device and not an impersonating device. But it is not a critical problem that an app instance's information is lost, e.g. if the app is removed or the device is destroyed (an annoyance that requires re-pairing, but not a critical issue).
It seems Firebase Anonymous Auth is a perfect match for this scenario - but the documentation hints that it should only be used as a temporary solution until users create an actual account. Are there any drawbacks to using anonymous auth as the sole authentication method for the solution? The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
Are there any drawbacks to using anonymous auth as the sole authentication method for the solution?
There isn't unless the user uninstalls the app.
The documentation hints that it should only be used as a temporary solution until users create an actual account.
Why a temporary solution? It's because anonymous accounts do not persist across application uninstalls. If a user uninstalls the app, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account. Unfortunately, there is no way to reclaim that token for the user.
The alternatives I see are some kind of hack using a custom token-based login or perhaps email/password auth.
IMHO, the best approach would be to use anonymous authentication but to also let the user the possibility to link their account with email and password or any other providers, like Google, Facebook, Instagram, and so on.
I am currently working on a project in which I am rewriting an old (late 1990s) web application in ASP.NET. Part of this application is a user authentication system, which is used to access a couple of pages on the site. The user credentials (username, password, etc.) are stored in a database table.
This is all pretty standard, but while working with this database I found, to my horror, that this data is stored in plaintext.
I am wondering what the best way would be to improve the security of this insecure system. Is there an easy method of taking the plaintext data, encrypting (or hashing) it, and reinserting it? Can I use .NET Forms Authentication to facilitate any of this, and is it a good option for user authentication in the new app?
Thanks!
If you are on a Windows network, I'd use Windows Auth, which uses Active Directory. That would allow your Systems Admin group/person to administer who has access to the application.
Forms Auth is a good idea if Windows Auth won't work for you.
If they won't give you the time to implement either of the auth frameworks, I'd definitely encrypt the passwords on the database. Write a Console app and encrypt the passwords using information found here: Encrypt and decrypt a string
Then you'd need to modify your existing app to check encrypted passwords instead of plaintext ones.
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.
Here's the flow I'm looking for for authentication:
Attempt to pull in the user's name from windows authentication
If that failed (user is external to network), use BASIC authentication to get the username/password.
Check the username/password against the SQL database. If windows, password isn't required, if BASIC authentication and password is incorrect, prompt again
Create the Identity object with the user name, and populate the user's roles via another SQL database call
This would need to be used for multiple applications.
What would be the best method of implementing this? Creating a HTTPModule? If so, what do I need to keep in mind (security, virtual directory setup, etc)
This type of authentication is called Mixed Mode authentication (some google searches on this will get you alot of hits). We have a flavor of this running on a site I work on, however there are some quirks to our setup that have to do with odd business requirements.
Here is an article that might get you going on the subject:
http://www.15seconds.com/Issue/050203.htm
It is a big topic to give a huge detailed explanation of how you could set it up in one post.
Good luck!