I've got a Rails App that uses Facebook for user accounts, and as of this evening, someone in Vietname has decided to (for whatever reason) use a bot to create fake accounts on my site using fake Facebook accounts. I'm getting about 2 new fake accounts / minute.
I've temporarily disabled registration, but I don't want to leave it that way, so I'm not sure what to do.
A couple things to note:
All the accounts use #yahoo.com or #ymail.com addresses
A lot of the accounts are registered by the same IP, but not all of them. It seems like he switches up the IP every 15 minutes or so.
I'm really at a loss, and I want to go to bed, but I can't until I find a solution to this. Help!
Make a capcha in registration form. If you already have a capcha in it then change the capcha generation mechanics. Also I think that your oponent made a script which is automaticly adds new user accounts to you web page, so as a temporary desicion you can change the url of registration handler.
You can use some techniques like limiting access to the application using something like a smart algo to block the IP it is requesting numerous account or limiting the account creation no more than a user from an IP.
And as specified if you know the pattern you can filter the request based on the pattern and deny any access.
Related
Is there a way to stop accounts.setAccountInfo from deleting an email if it is the last standing login ID?
Currently if I have 2 verified emails both loginIds and issue 2 requests removing one email at a time (I know I can pass a comma separated list) I end up with an account that can't login anymore as no login Id is left.
Both return 200 ok and no error code.
I've looked for an etag implementation so I can at least force some sort of an optimistic lock but couldn't find support for it.
Any ideas?
This is by design, as in the case a user's email(s) were compromised, there needs to be a way to disable login of the account until the user can have their information updated via a customer service representative. There is no out-of-the-box way for an end-user to use this particular parameter, so, unless a currently logged in user is manually calling the method from the JS console, there is no way for this scenario to accidentally happen.
From the server-side, if you are worried about a specific application from calling this method and require restricting a specific app from accessing this particular API you can assign the application key to a permissions group with restricted permissions. ref:https://developers.gigya.com/display/GD/Console+Administration#ConsoleAdministration-PermissionGroups
If you think this behavior should change, please open a ticket from your Gigya/CDC account dashboard for investigation.
I'm using omniauth to authenticate a user via Google. When the user logs in via Google, I check if an account already exists with the same email (if it does, I reject sign in).
When I create the new User model, I give it the name, email, and the URL of the user's 'image'. I am not sure how to dynamically update the information in my database when the user changes their settings on Google, including the image_url when they change their profile image.
A good example of this scenario is this Stack Overflow; I signed up to SO with Google. Having changed my profile image (recently), I was surprised to find that my old Google image remains attached to my SO profile. Maybe it takes time for Google to change the old URL to represent the new image. I have noticed that some parts of Google use my new image, and other parts continue to use my old. Of course, this question doesn't have much to do with Google's profile image mechanism, I just think this is a perfect example.
My questions are:
Should I want to do this, or should I instead provide the user the ability to change their details through my site, completely ignoring what happens to their Google profile?
If I should do this, what is the best way? Checking on every login isn't ideal as the user might not log out for days or even weeks.
Should I be storing the Google auth token? Currently, I'm not as I don't need to make any Google API calls -- I only use OAuth for the 'uid' to ensure it's the same account logging in (the email isn't used at all).
I don't think the answer will be "don't store user info, query Google instead", so I'm not really sure what best practice is in this scenario. A brief walkthrough on proper procedure would be very helpful.
Normally, oauth applications will use the endpoint /me.json as part of the login process: After the user is signed in, the app uses that fresh token to query their profile info right away and update data. In your case, I understand you ignore when email already exists. You should probably add a new step there, to update your local record if it already exists instead of purely ignoring it.
In other words, your app wont be automatically notified if users change their profile pictures. But you can always use their log in action to fetch the latest image (or use their token in a background job that runs every n periods of time using something like cron + whenever, assuming the oauth scope authorizes offline access)
I am investigating two factor authentication for my Rails app. There are many solutions available, like devise-two-factor, a more do it yourself approach or with phone codes.
They all look fine, but what I am really looking for is the approach Whatsapp is using, where you have to authenticate on a device just one time and the device is trusted and you don't have to do it again, unless you clear the browser. If you try to login from another device, then you have to authenticate with a code again.
Is there a solution like this available? Or is it easy to create a solution for this?
I can imagine you create a table with for every user trusted IP addresses and the last login timestamp to see if two factor authentication is needed when a user tries to login, but I'm not sure that is everything to it?
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.
I'm trying to use MyOpenID for my sign-in, but it doesn't seem to be sharing the email address.
If I use Google or others I do seem to get the email address, though. I thought that this was a standard field to return.
I even see some documentation here that seems to suggest they would share email:
https://rpxnow.com/docs/providers
(I'm using Ruby on Rails and Janrain for this project)
One interesting thing is that if I setup an identity page on MyOpenId, then the email IS shared with my application. I thought that there was supposed to be a way when logging in with MyOpenID to specify what data is shared during "SimpleRegistration"?
The problem was that I was testing with my own MyOpenId account and the very first time I logged in to my development server I had not paid enough attention.
When logging in the first time it said something along the lines of "blah site is asking you to share information with it. Click here to use an existing persona or to create a new one. I didn't select one and it defaulted to "don't ask again".
I was able to fix this by going in to MyOpenId and revoking permission for my site. Then the next time I logged in it asked me again and it worked.