I am trying to make an ASP.NET MVC Azure-hosted website role that allows third-party authentication.
The client might not want me to add SQL server since it costs money, and I can cut back since all of my data comes from CRM. My problem is that DotNetOpenAuth, the library that supports the authentication, appears to require some database tables for storage. However I do not want to use any storage since I want to put all my data (and the auth token) in CRM.
1) If I don't use DB to persist the token, then is it a good idea to use encrypted cookie/server-side sessions? What do I have to modify?
2) Is in-memory, non-DB sessions from 1)* scalable in Azure?
3) Is there any way to make DotNetOpenAuth (WebSecurity class) work without relying on a db?
DotnetOpenAuth doesn't require database, you provide your own implementations of few interfaces, nowhere db is required.
Tokens are not persisted. Instead, tokens contain username and scopes encrypted with a private key of the authentication server. This way all you need is the public key in the resource server to decrypt the token (the ICryptoKeyStore interface).
You could as well persist keys in the filesystem or elsewhere.
Related
For our portal development, we have decided to use Apigee to expose the web service to the portal. For which currently I am storing the API Key and Api URL in the properties file of the project. Can anyone help with some pointers on how else can I save the API key apart from the properties file.
Any pointers will be helpful in this case.
Regards
Aswathy
Typically the API key will be persisted by the the API consumer - usually an App of some kind. In case of Mobile Apps, each of them have an API Key or Client ID that is saved inside the app usually in some kind of secure data store. For other kinds of API consumers such as web apps the API Key may be persisted within a secure vault or an database that has some encryption features.
I assume your web portal app resides on a secure machine inside your enterprise and that this machine is access restricted. If this is the case bare minimum security is taken care of
However, If the key is a high privilege key and you can access APIs with key alone(ie without a secret), it is not advisable to keep it in plain text.
You can
1. Encrypt and store it in the config file and decrypt at runtime
2. Encrypt and store in Database or other secure storage you use for storing credentials.
I am developing an asp.net web api app, and using OWIN and identity to implement oauth for my aplication security. For each registered user, I also save a client id and hash as described here. But I dont want other developers be able to use my api and create their own app using the client id (and other credentials) they have.
Is it possible ?
First thing first, you have to encrypt your network traffic between mobile device and API. Because attackers can obtain sensitive data (which is API Token in this case) via proxy . Also you need to do SSL Pinning because of you need to be sure about public key is yours, otherwise attackers manage to get sensitive data again with same method. ( Please check out : https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning )
You shouldn't authenticate users with username/password. I suggest to you use api key, therefor you can send user actions to server side like following patterns.
https://example.com/api/APIKEYOVERHERE/action
Als you can watch this talk about Secure Your API - Tips for REST + JSON Developers.
https://www.youtube.com/watch?v=FeSdFhsKGG0
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.
I am developing an application using the ASP.NET Web API, and I am using authentication with username / password being consumed by a WPF client and I am using SSL, but for safety application I want to integrate with a client cerficate (x.509).
I'm following this example:
http://www.codeproject.com/Tips/159604/SSL-MakeCert-pvk2pfx-Client-Server-Certificate-Gen
The example displays setting a key on the server and the client. Currently I have several companies that consume the same service, with multiple users per company.
My question is, can I use one client key for a company, ie: multiple users accessing the same key?
If not, is there a better way?
If your service is using SSL, why do you want overhead of a certificate based security? Have you considered performance impact it may have?
If you want to go ahead with a certificate based PKI type of encryption for your services, then you can even share the same public key with all the users across all your client. Just keep the private key really private.
I'm developing a site that will display confidential readonly information,
with data fetched from a WCF service.
My question:
What is the best approach to user management across different information pages.
The service returns a collection with customer info after a secure login.
My idea is to have a Customer object class that is stored in session.
Is it possible to use things like HttpContext.Current.User.Identity.IsAuthenticated
followed by HttpContext.Current.Session["UserId"] without using a database with role-based security?
Would I be better off with a combination of local database, Linq to SQL or datasets rather than using
just class objects for data fetched from service?
thanks,
nakori
If you have no need of tracking the user's identity within your application, just use session as you indicated.
But the HttpContext.Current.User.Identity.IsAuthenticated and such relies on the user having authenticated with your site in some way or another (or it will always come back as false). Authenticating with the web site doesn't necessarily need a database though. You can setup users directly in web.config, xml files, or use AD or some other authentication mechanism that doesn't use a traditional database.
But unless you need to authenticate the users, you can probably do what you want using the server's session object and/or cookies.
You don't need a local database - but best practice is to have the user authenticate. The two options are via a database and or via AD if this is an internal site.
You might as well create a new WCF service to perform the authentication since you've already got your database functionality separate. This will also let you access databases that aren't local.