There are many games which use login but are in client side... But, can the games like Clash of Clans, Clash Royale and others be by-passed the login sequence and open up with a random profile though it uses Google Play games for verification, there must be some method? (its not related to 'hacking' but quite to 'enthusiastic'
Most of the logic to handle an anonymous profile is on the back end server. You can use an approach like Firebase Anonymous Authentication on Android and iOS to identify the player. Firebase Authentication also has the added advantage of being able to associate multiple authentication types to the same user, so if the game player decides to sign in with Google, or Facebook, for example, they won't lose anything they did as the anonymous user.
No, until we have access to Google Account which can help in by-passing the login sequence ('quite' close to it) .. The other methods might fall under other catagory so I'd rather prevent myself falling into that!
Related
I implement a web application (with Python+Django - to the extent that matters). Users can log in normally with username and password, but in addition I want to provide an API which users use to script the interaction with my site.
For the API authentication my plan was to do something like this:
In the database I create table with 'tokens' - i.e. random strings which point to the user database.
The user gets a token string.
For every API call the user passes the token string along with their request
In the API implementation the code:
Verify the token.
Log the correct user in and execute the API function as the user matching the token.
Log the user out again.
Return the result
Does this make sense? On the one hand it seems very simple - on the other hand it feels quite homemade, something I have heard is not recommended when it comes to security related topics?
I would wholeheartedly recommend looking at django-rest-framework
https://www.django-rest-framework.org/
It literally does all of that and more!
Nope, not a sales person, just a developer :)
It handles quite literally any use case you can think of, and I would be happy to discuss at great length any its not suitable for.
It handles:
Authentication
Parsing
Encoding
View or object level permissions
Object serialisation
Object creation
Object deletion
Automatically generated documentation
Several authentication methods, including custom managed methods
And a bunch of other stuff that makes writing API's in Django much easier
All in all it supports most if not all use cases.
EDIT
It is worth noting that there is a very good reason DRF has short lived access tokens. That is because of security.
Let's say a malicious actor gets hold of your short lived access token, thats a lot better than a "long life" one as you described.
It's worth weighing up security and ease of access, security and protecting your users should always paramount.
Futhermore, I would recommend taking a look at DRF Knox, which is recommended in the authentication section of the DRF docs:
https://github.com/James1345/django-rest-knox
Is it possible to ban users from using a Facebook application?
I'm not talking about the canvas or the discussions board (which is what I've found by looking around), but the application itself, that is, causing errors or preventing actions whenever the user tries to use the Graph API (in my specific case, an Android app that uses the Graph API to provide some features).
The scenario I'm envisaging is something like this:
user authenticates app to use its features and gets the access_token;
user uses the Graph API according to the app permissions;
user someday does something he shouldn't;
user is banned and, even if the access_token is still valid, Graph API requests fail, and will always fail even when deauthorizing and authorizing the app again.
Is this possible using the Graph API or the developers app console on Facebook, right now, or is there really no way to prevent users from misusing your application? I guess I may do something "out of band" to enforce this somehow, but being able to do it at the Facebook level as well would be much more effective and harder to circumvent.
See https://developers.facebook.com/docs/reference/api/application/
Use the 'banned' connection of the Application object to ban specific users from your App - you'll need the App access token to do this
Just create a blacklist of specific Facebook User IDs, and check the user's ID against the blacklist when they log into your app.
If the blacklist matches, show a message telling them that they are banned and don't allow access to any functionality.
This seems to be a reoccurring problem for me as I seem to gravitate around mobile applications the last few years. I want to authenticate and authorize mobile users in addition to web users. I need to make this seamless enough so that users can ease into having a web account without causing interruption to their data. I want the solution to be architectural in topic, not specific to any language/framework.
Requirements/Assumptions
Mobile users must be able to use the native application without a login, including for contributing content (marking favorites, uploading photos, etc).
Mobile user should be securely and uniquely authenticating to the web service even without specifying account credentials.
Mobile user may have multiple devices, which will be unaware of each other.
Mobile user should be able to Register/Login, which should roll in any content into the account's ownership. This "synchronization" should occur with each account that is subsequently logged in.
It should not matter whether an account was created on mobile or web.
Architectures Considered
NO SHIRT, NO SHOES, NO LOGIN = NO CONTRIBUTION. Require login to contribute content of any kind. This prevents the need to "synchronize" device accounts with a master account. Simply require a single username/password + tokens in order for devices to login. Server objects: User, Role
Multi-device self-authentication. Server negotiates with device and hands it credentials which the device stores. Each device self-authenticates and is associated with an anonymous account until Register/Login occurs. If Register occurs, anonymous account is converted into known account. If Login occurs, content from anonymous account is moved over to known account and then thrown away. Devices that lose the self-authentication details will get new authentication details, and the previous anonymous account is abandoned (and then hopefully later thrown away) and not restorable since it was never converted into a known account. Server objects: User, Role, Device
What do you think is a good solution? One of these, or something else?
I would like to propose an idea similar to 2.
Generate an UUID per mobile device. It will serve to identify the device on later occurences when the user generates content and the content is sent to the server.
If, at any time later, the user wants to create an web account, he may register either on the web or on the device. If the user already owns a web account, he may opt to provide the existing credentials on his mobile device once (or devices) and the device is linked to his web account on the server-side.
On the server side, I would allow two different types of entities serving as identities: Web Users which are authenticated by credentials (OpenID comes to my mind as an addition) and devices which are authenticated by their GUID without user interference. Naturally, a web user entity may own several device entities. A device entity is linked to an account when the user opts to link his device to an existing account. Content is generally associated with an identity.
The linkage between user and device is kept and could also be used to display the origination of content.
You would not need to create/drop/convert accounts with generated credentials for mobile users. You would also not need to store the credentials on the mobile device.
There are still some security considerations left open, depending on the criticality of the context of your application. Without any security measures, an attacker would find it easy to abuse the UUID.
I think this is being looked at from the wrong direction. Define an identity on the server as being defined by an arbitrary value. Probably just a DB sequence. Associate any demographic information (name, email...) and usage history with this identity.
Separately, define an authentication entity on the server. This could be a user/password. It could be a device GUID/UUID. It could be a federated ID like OpenID. A given identity can have (and often will in your use-case) multiple associated authentication-entities. Very possibly multiple authentication-identities of the same type. (e.g. GUID for my smartphone, GUID for my iPad...)
Your front-ends (whether web or app-based), use a defined API to authenticate a user; using whichever of the mechanisms that front-end supports.
In some cases (particularly the native app), the presentation of an unknown ID triggers the creation of a new identity. However, as someone pointed out, in this situation you should ask the user if they want to connect to an existing identity. They need to provide authentication as that identity (once) in order to establish that connection.
One other point, whatever the server uses to uniquely specify an identity should be a value that is never provided to a client. Clients only know about the authentication mechanism and its data. That is, the GUID/UUID, username/password,...
In addition to the techniques listed above, something like OAuth is more secure than a locally-generated GUID. Those are one of a: easily-determined or b: easily-lost. If the value is highly predictable (say telephone #) it is easily spoofed. If it is generated at runtime and includes a hard-to-predict value like the hash of the current time when it is first generated, then it must be stored on the device and can be easily lost if the device is wiped. Good GUIDs can be generated, but they are often very type-of-device specific. Things like device serial numbers retrieved from ROM, IMEIs,... This is readily doable. But, is a lot more specific-device dependent than I'd likely be comfortable with.
The biggest real hurdle I see in this whole approach is that it will be awkward to allow an existing device-only (no username/password) user to sit down at a PC browser and connect to his existing account.
Number 2 is good enough as base decision. Users hate registration ;) So ability to use service without registration is good idea.
You can use GUID/UUID to identify devise. And use it as anonymous login before user login.
But what to do if 2 (or more) people use 1 device? Or device will be losed, stolen?
I think no one of the points cover these cases.
I have no idea what kind of web service you architect so can't advise more.
One solution is with a biometric. If the mobile device has biometric sensor, such as a finger print reader, user will enroll biometric with the device (only- due to privacy issues) at the time of purchase. The applications can be written such that every secure transaction requires the user to authenticate the biometric.
This does not seem to be too far off. Motorola Atrix has a fingerprint sensor...
I have a question as to how / what the best approaches are to using OpenId and also providing the ability to stay logged in.
If i look at Stackoverflow for example i have logged in using Google and if i close by browser and come back it still has me as logged in.
However, i am not logged into Google and moreoever I have removed stackoverflow from the list of authorised services which have access to your Google account. I would naively expect that stackoverflow would prompt me to login again but it doesn't.
So my question is, what are the best practices regarding OpenId and remembering authenticated users across sessions?
OpenID is still pretty new and several relying parties are trying out new and different ways to implement OpenID. There is a work in progress best practices document for relying parties hosted by the OpenID foundation. In particular, they address the question of cookies and session lengths in their last section. Definitely an interesting idea to use persistent claimed_id cookies rather than persistent session cookies in order to make the user's life easier -- they only have to log out of their OP and close the browser.
Personally I find the behavior you're describing on StackOverflow pretty natural. If OpenID were out of the picture and you were logged into a username/password web site on two different computers with a persistent cookie (a very common scenario), and you changed your password on one, I wouldn't be surprised if the other computer still had me logged in. You could call that a security hole, but it's still normal practice. So normal in fact that Gmail recently added a display at the bottom of your Inbox screen that tells you where else you're logged in and gives you the opportunity to invalidate their session cookie.
I would suggest that a similar approach could be taken by any RP, regardless of the authentication method. And that would probably mitigate the security concern you have.
Stack overflow probably uses a cookie to remember you as user number xyz or session id 1234. After authentication, OpenID has nothing at all to do with the session anymore. SO doesn't have the ability to see if you are still logged in to Google so this seems only natural.
I need to make a simple knowledge-base type application to use in company internal network. To make it simple and fast to use for end-users I would like to skip all the login in part (as it will be only visible to internal network users who we trust anyway) and automaticly pull the domain user name from the user and put it into the database (don't want people to waste time manually entering their name; the littler time they waste using the app, the higher chance they will actually use it).
So, is it possible to get that kind of information on a server? Do windows browsers send it in some headers that I could trust to be there?
If you are using IIS and Internet Explorer, you could turn on 'Integrated Windows Authentication' (NTLM authentication). This causes IE to automatically authenticate the user using your domain infrastructure. After automatic login, you can access the user name using the environment variable LOGON_USER. There is also a module for Apache (mod_ntlm) for this purpose, although I don't know its status.
Maybe you could event try to implement NTLM authentication yourself, but this will certainly be a lot of work.
Other than that, there seems to be no way since no reasonable browser will send the user name...
EDIT: It seems that python-win32 extensions or python-ntlm could do the trick, check out this thread. You still have to integrate it into Django, though.