Some people are using this data validation pattern to protect forms:
A youtube video from Google for Education uses this pattern.
A similar scenario to mine with a similarly proposed solution.
Since Google for Education showcases this pattern, I want to believe it is reasonably secure. But I also understand the above solution is client-side validation, based on this answer.
Logically, doesn't this imply the validation values and logic can be exposed by scraping/viewing the source? How safe is it to store passwords and unique IDs as a regex in these validation fields?
For context, I'm hoping to use Google Forms + GAS for verified, unique form submissions from a set of non-google account emails while reducing quota usage from spam/misuse.
It's not secure. All client side validations are insecure by design. Pattern validation passwords are visible in the source code. Having said that, a single password for multiple users is also insecure. All it takes is one user compromise to invalidate the whole thing.
If you need a fully secure solution, create your own form with HtmlService with oauth authorization and Google identity.
Related
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.
Currently using the OAuth server side one-time-code flow, discussed here:
https://developers.google.com/+/web/signin/server-side-flow
Works perfectly for google login.
I want the ability, though, to limit this login to only work for users that belong to a specific apps domain.
Is there any way to enforce this through the api?
OR am I limited to only doing this on my end after google authentication by regexing the email domain? (I would like to avoid this).
Thanks!
There is no support for doing this through Google login. We could allow a developer to set some restrictions on the client id if there are good use cases and a lot of developers would benefit with it. The primary issue I see with is the error message that we have to display to the user. It is better to display that error (and explain) on your site.
In general, as a good practice, you would always want to do the checks on your system/services regarding the authorized user (e.g. check domain)
The only way I can see to do this on the API is to use the fully server side flow (OpenID Connect).
The docs are here:
https://developers.google.com/accounts/docs/OpenIDConnect
With the parameter of interest here:
https://developers.google.com/accounts/docs/OpenIDConnect#hd-param
It doesn't appear to be possible with the server side one time code flow
Hello Guys I have been using ReCaptcha in my apps register forms. I have seen a lot of examples of captcha in signup forms. My question is if I implement a custom Captcha such as when a user Registers I send a confirmation email and a auto generated code/passphrase/ turing test that is converted into an image with some sort of effects to distort it. Since we are sending a confirmation email anyway why not use it for a turing test and get rid of captcha in the form?
I understand that the advantages/disadvantages can be
1) If the user has entered an incorrect email then he wont get access to turing test but that is the whole point of a confirmation email.
2) Distorted image may not be readable and/or refresh-able but since we are just distorting sth that is an autogenerated by code we can make it a little bit more readable than scanned images that captcha images.
I can only think of the above two situations. Please point out any thing else that you think should be taken into consideration.
Having a CAPTCHA that covers the registration process is important to protect you from bots whose sole purpose is to generate as many users as possible with the intent of using those users to post/add content on your site with links back to a site that they are trying to improve SEO on. This is only one way in which malicious users can utilize multiple accounts on a site for their own purposes.
The registration email protects your users as much as you by creating a way a means of resetting lost passwords, proving ownership, etc.
Both parts should be included when validating users. I also recommend running ip counting on new user attempts. Typically, locking after the 2nd user created is fairly safe as long as you provide a link that states why they have been prevented and a means of creating additional accounts on that ip.
None of these procedures is failsafe but together they provide a medium level of anti-spam protection. Of course, these days people defer user maintenance to social media sites like Google and Facebook.
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.
Are there Custom ASP.NET Membership Providers for sale with added security?
For example, the ability to have multiple Questions/Answers that are randomly presented for Password reset, set number of login attempts, force password resets every 30 days, prevent duplicate passwords for new password for a certain period of time, etc
I've recently updated my custom provider with some of your requested features. Unfortunately it's not exactly for sale, but I did want to tell you that it wouldn't be terribly difficult to do on your own.
The multiple question/answer feature and the force reset (password expiration) actually can be implemented using any provider because they're not directly enforced by the provider. To enable Password Resets you could simply define a constant in your appSettings, i.e. "PasswordLifetimeInDays". Then in your Login page simply override the Authenticate method and inspected the LastPasswordChange property of the MembershipUser. If their password has expired then redirect them to a ChangePassword page, otherwise log them in. Check out this article for a walk through of implementing this feature.
The pre-generated question scenario is also something that doesn't really fit in as provider functionality. Although, a third party solution could contain this mechanism in a separate API I suppose.
The SqlMembershipProvider already provides a way to set the number of login attempts via the MaxInvalidPasswordAttempts attribute.
Really, the duplicate passwords functionality is the only piece that truly belongs in the provider implementation as it requires an additional table to track the password history.
Let me know if you ever decide to implement this stuff on your own and I could offer some more guidance.