I manage a couple of older webapps that at some point have been converted to Laravel. They both allow login via email/password combinations or FaceBook logins, using Socialite for the latter.
FaceBook has advised me I need to confirm I meet the requirements for:
[A] Enforce encryption at rest for all Platform Data storage (e.g., all database files, backups, object storage buckets)
More clarification has not been forthcoming, and FB docs for developers tend to be self-referencing without really being clear. The inference here seems to be that any data provided by FaceBook via their API must be encrypted in the DB.
This can partly be achieved through casting certain User attributes to "encrypted" and applying this to the DB fields retrospectively for existing FB and non-FB users. However I don't see any obvious way of encrypting email address and still being able to use Laravel authentication in any fairly standard way. I can see how it could be made to work, though solutions seems to be onerous and rather awkward
As I find Laravel tends to offer straightforward ways of achieving routine functionality, and I don't think providing email/password logins is especially unusual, I'm surprised to find no information at all about how to work around this.
Am I mis-understanding the requirements here? Are others in a similar position not coming across these Data Protection Assessment requirements, or are they just telling FB "sure, everything's as it should be" and applying their own standard of security to user data?
I don't think this is off-topic or too vague, but appreciate it might be. If the question stays up, any advice is welcome.
Thanks
Edit:
Moved to github Laravel discussions
https://github.com/laravel/framework/discussions/42397
If you examine firebase cms, you will understand better what you mean.
must be talking about encryption of repositories like automatic backup.
Related
I am writing an app that uses Parse Server, with Auth0 as the authentication provider. For unrelated reasons, we need to use Auth0 rather than Parse for user management.
I'm having trouble figuring out how to "link" a user authenticated via Auth0 to Objects in Parse Server. Without this, the authenticated user will not have permission to write to his/her Objects on the Parse Server. I believe my issue is similar to this question, which has no solution: here.
I have found many articles discussing the migration of users from Parse to Auth0, but am finding surprisingly little documentation on how to link those users to Parse. There is one article (I believe written by the same person who posted the question I linked to), but I couldn't get it to work, and it involves storing passwords in cleartext in Javascript.
I thought to create a default Parse user that would simply own all the objects in Parse. This would be invisible to the authenticated end-user so they wouldn't know, but that's just security by obscurity and doesn't seem like a good approach.
If anyone has suggestions on how to approach this, or has done it before, I'm interested to read your suggestions. Thank you very much.
Auth0 supports the most common and used authentication protocols (OAuth2/OIDC, SAML and WS-Federation) so configuring an application to rely on Auth0 is really easy when that application already talks one of the previously mentioned protocols.
According to the Parse Server Wiki, it does support custom authentication leveraging OAuth so that seems your best starting point for integrating Auth0 with a Parse Server based application.
It is possible to leverage the OAuth support with any 3rd party authentication that you bring in.
Disclaimer: I never used the Parse service or Parse Server so I'm assuming that when you mean linking Parse objects to users this can be accomplished by simply having an authenticated user in Parse and the identity of that user is just verified and proven by Auth0 instead of something like built-in username/passwords managed by Parse itself.
browsing in this website, i found some interesting suggestions. SocialAuth.net and DotNetOpenAuth.
i started using SocialAuth. It's very simple to use and it worked (i only tried with google so far thou). My only problem with this library is that it doesn't provide a way to retrieve the Contacts from the providers it offers without logging you in with the new (or latest) provider you requested the list of Contacts.
in other words, i MUST sing in my people with a local username and password for security reasons. BUT i would like to benefit from this library's feature of getting contacts from different providers. Thing is that it overrides my currently logged in user (using FormsAuthentication) for the Authentication Token sent by google.
Has anybody confronted this issue?
Does DotNetOpenAuth doesn't have this flaw?
Thanks
Are you sure you understand OAuth?
It could be that I misread your question, and to be honest I don't have any experience with socialAuth.net (will look into it).
To me it seems like you think socialAuth.net requires you to login, I know this is not the fact in DotNetOpenAuth. Only place you need to login (if you aren't already) is the service you are connecting with (Twitter, Facebook, etc.)
Of course it could also be I just answered your question :D
Maybe you should check the last changes in source:
http://code.google.com/p/socialauth-net/source/list
As you can see, in r320 it seems they have fixed this issue
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D
Ok, I'm new to web development, so I might be getting some of these terms wrong. I apologize in advance.
I am having trouble understanding the different elements of authentication. Every method seems to be advised against by someone, though not always with clear reasons. I am building a web app for a company that will have access to a database, so I would like to make sure it is secure.
So the there are three places I have seen commonly used to store information.
FormsAuthentication.SetAuthCookie(). This stores a session cookie that will exprire with the browser, and nothing sensitive is on the client. However, it can only store one value. This stackoverflow answer shows a method of storing multiple values here, but the guy who gives it says not to use it, though not why.
FormsAuthenticationTicket. I don't know where this information is stored, but it allows for a simple method of storing multiple values. Securing it, according to the documentation requires calling Encrpty() to store, and decrypt() to retrieve. This seems wasteful, but what do I know.
Session["SomeRef"] = new CustomObject(). The second answer in this question explains how to do this, but a comment to it calls it dangerous because it can be stolen. This looks like the best method to me, because the information is still stored on the server, and can store multiple values.
I cannot find any comparisons for these methods, or good explanations on the "best practice" way of storing multiple pieces of information after authenticating a user. The information is just the User's name and their userId.
Here is some further clarification to help you decide.
SetAuthCookie can be implemented in a way to store multiple values. In practice, however, you usually can't store enough to avoid a database lookup. It's best to store the user name (unique identifier) and load more information during the request. As your question suggests, you shouldn't store sensitive information on it. You should assume that all information sent in a cookie can be decrypted and read and you should take precautions that that information can't be used maliciously. All session cookies can be stolen and I'll explain why in a moment.
FormsAuthenticationTicket is the same API as SetAuthCookie but at a lower level in the Framework. With SetAuthCookie, Encrypt() and Decrypt() should be happening anyway (it's the default configuration.) It's not wasteful but use method 1 instead because it's easier.
Session has some limitations. Notably, by default it's process-dependent. That means that when the server restarts or more than one web server is involved, your session is lost and you have to authenticate again. It is the easiest to use and fastest when using the default memory session storage (InProc). You can use sql storage or a dedicated session server to overcome the process-dependency.
All three methods are considered dangerous for the same reason all cookie-based authentication systems are dangerous: because the cookie's value can be sniffed over wireless and reused to take over a session. This is known as sidejacking and it also applies to scenarios 1 and 2. The way to prevent this is to implement HTTPS. Then, the cookie transimission (and everything else) is encrypted at the network level and can't be stolen.
TLDR; Use SetAuthCookie and HTTPS
NOTE this answer has been edited several times for clarity.
I can't imagine that there doesn't exist an efficient, lightweight, secure authentication and authorization library for ASP.NET applications that is easy to use in e.g. your controllers and views. I read tons of articles and I performed a zillion searches, but did not find one yet. Does anyone know of such a library? Or did anyone create one himself and is willing to share?
The ASP.NET authentication system is mainly based on the Username rather than on UserId. I really don't understand that. Imagine you want to create a blog with comments. A user can register and post a comment. Two well-known MVC examples (Nerddinner and MVC Music Store) use the default asp.net authentication system (membershipprovider / identy / principal etc.) and use the Username to store the user that belongs to some object, e.g. "HostedBy"-field.
To me, this seems not a very good practice:
It's not possible to change username without having to change all the related records.
Why not us an int as Id? You need just 8 bytes to store 16 million users. Unless you limit the username to 8 byte-characters, it is less efficient in terms of storage space.
A string-based relationship seems not very efficient, as string based lookups are slower than integer based lookups.
Oke, I can imagine why you want to use a Guid and not an int, because that is virtually impossible to guess and to remember and that could increase security in some way; if that's the reason, that's fine to me.
But, then remains the question why the IIdentity interface makes just the Username available and NOT the UserId. If you use the UserId as foreign key, it's hard to e.g. fetch a list of all the posts of the current logged in user: you always need a database lookup to fetch the UserId that belongs to the username.
Another thing I wonder about is that the authentication system seems rather bloated. My best guess is that at at most 90% of the users will use an authentication system for just one application. So, why create default functionality to make it capable of serving multiple applications? (the application column in aspnet_Users).
If you don't care about these things, it's might be allright, but, I want to prepare for 16+ million users, don't you? Or, I want to server my pages under 50ms... So.. why the heck did Microsoft build the default authentication system this way? It seems pretty bloated and crappy to me.
A related question (which doesn't give answer to mine):
How can I access UserId in ASP.NET Membership without using Membership.GetUser()?
OK, you dislike the ASP.NET Membership Provider. If you're an NHibernate shop, then you could take a look at Rhino Security by Ayende Rahien.