I want login system in my capsule so that i can provide user more recommendation based on their profile of interest. So far, neither I am able to find any document related to login facility nor any example. It would be appreciated if will get any document or example.
Bixby supports logging in through OAuth 2.0, and this is the best way to guide your users through a login flow.
You will need to provide your own service to handle this OAuth flow, as Bixby Developer Center does not offer any web hosting services.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/actions.using-oauth
Also is there a possibility that user can user can use app as a guest
user if no login credentials?
When you define your endpoints, you can define Actions that require OAuth and other Actions that do not require OAuth and the latter ones will define the "guest user" flow that is capable within your capsule prior to logging in.
If you don't need all the features of OAuth, and only need to store a few things between sessions with the same user, you may use the $vivContext.bixbyUserId value as an anonymous, but unique identifier for a user, and store their preferences using that id as a key, in a 3rd party database that you maintain.
I've done this with the "My Brain" capsule, to store quick memories/notes for users, without any requirement that they login or establish an account. I've created a tutorial version of the My Brain capsule that outlines the steps you need to use AWS for this purpose. Please feel free to clone or fork it and customize it for your needs.
I want to release my application in play store and app store.
But, That store require PrivacyPolicyUrI But I don't use signup system
And most application has terms of policy in their signup view
it is essential?
So...
PrivacyPolicy is required for non-signup application, too?
Terms of policy is required even if I'm just developer not company?
Yes, a Privacy Policy is required even for apps that do not require sign-up. However, a sign-up screen is good as you can use the clickwrap method of getting active constent from users to accept your Privacy Policy.
The requirement of a Privacy Policy is due to sensitive permissions you app may ask.
You can find the list of those permissions here: https://play.google.com/about/privacy-security/personal-sensitive/
Even if you don’t need and ask those permissions, make sure you know what third parties you use in the app that might trigger this requirement (eg. AdMob).
You’ll need to add the URL to the Privacy Policy URL at Store Listing section. The link must be publicly accessible. Google will not host it for you.
A Terms of Service is not required, but it’s useful to add rules regarding user-generated content, unacceptable behaviour and so on. For example, it’s useful to add intellectual property clauses, ownership over your content and licenses over user-generated content clauses.
I've read about security best practices saying that inactive user accounts should be disabled and even deleted to avoid security issues like unauthorized use. I can see that being true for regular username and password authentication sites, however my application was built to work only with Facebook groups and as such the only way to login or create a new account is to use the Facebook login.
The argument can be said that someone malicious could take control of one of my users' Facebook accounts and then use it access my application. Although that is true if they have control of a Facebook account my application would never know it's a malicious person so I don't see that as a valid criteria to use in determining if the account should be disabled.
Furthermore if a user is inactive and wants to become active again since it's Facebook login there really is no reason for them to go through some kind of reactivation process like confirming their email or changing their password.
I must be missing something here because it's certainly mentioned as a best practice to disable accounts but since my only login method is Facebook (OAuth) I can't come up with a valid reason to disable/delete inactive accounts.
Regarding other methods of unauthorized access I have security measures in place so I'd like to keep the answers relevant to the login method.
Please enlighten me if I've missed something.
If you have decided that your application needs to use Facebook authentication, then your system's identities will only be as traceable as Facebook's identity management permits. (And don't expect Facebook to help you by disabling / blocking users at their end ...)
You need to design it accordingly:
Don't make any assumptions that users will behave properly.
Don't rely on login controls to keep out malicious users.
Put in your own (sufficient) defenses against malicious behavior into your own system.
You are correct that disabling an account in your system won't achieve much if you also allow the user to (easily) reenable it. Given that it is easy to create (effectively) untraceable Facebook accounts, the chances are that a typical malicious actor will not just rely on old accounts. They may use a brand new account and connect from an IP address that you have never seen.
There are some things that you could do though. For example, implement mechanisms to do the following:
Make sure that users simply cannot upload dangerous content (e.g. files with trojans, web content with dangerous links or scripts.
Allow administrative locking an existing account or OAuth identity,
Allow blocking of creation of accounts or access in from specified IP addresses or ranges,
Keep an audit trail so that you can watch the history of user behavior.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'd like to know what people consider best practice for securing the Admin sections of websites, specifically from an authentication/access point of view.
Of course there are obvious things, such as using SSL and logging all access, but I'm wondering just where above these basic steps people consider the bar to be set.
For example:
Are you just relying on the same authentication mechanism that you use for normal users? If not, what?
Are you running the Admin section in the same 'application domain'?
What steps do you take to make the admin section undiscovered? (or do you reject the whole 'obscurity' thing)
So far, suggestions from answerers include:
Introduce an artificial server-side pause into each admin password check to prevent brute force attacks [Developer Art]
Use separate login pages for users and admin using the same DB table (to stop XSRF and session-stealing granting access to admin areas) [Thief Master]
Consider also adding webserver native authentication to the admin area (e.g. via .htaccess) [Thief Master]
Consider blocking users IP after a number of failed admin login attempts [Thief Master]
Add captcha after failed admin login attempts [Thief Master]
Provide equally strong mechanisms (using the above techniques) for users as well as admins (e.g. don't treat admins specially) [Lo'oris]
Consider Second level authentication (e.g. client certificates, smart cards, cardspace, etc.) [JoeGeeky]
Only allow access from trusted IPs/Domains, add check to basic HTTP pipeline (via e.g. HttpModules) if possible. [JoeGeeky]
[ASP.NET] Lock down IPrincipal & Principal (make them immutable and non-enumerable) [JoeGeeky]
Federate Rights Elevation - e.g. email other admins when any admin's rights are upgraded.
[JoeGeeky]
Consider fine-grained rights for admins - e.g. rather than roles based rights, define rights for indicidual actions per admin [JoeGeeky]
Restrict creation of admins - e.g. Admins cannot change or create other admin accounts. Use a locked-down 'superadmin' client for this. [JoeGeeky]
Consider Client Side SSL Certificates, or RSA type keyfobs (electronic tokens) [Daniel Papasian]
If using cookies for Authentication, use separate cookies for admin and normal pages, by e.g. putting the admin section on a different domain. [Daniel Papasian]
If practical, consider keeping the admin site on a private subnet, off the public internet. [John Hartsock]
Reissue auth/session tickets when moving between admin/normal usage contexts of the website [Richard JP Le Guen]
These are all good answers... I generally like to add a couple additional layers for my administrative sections. Although I've used a few variations on a theme, they generally include one of the following:
Second level authentication: This could include client certificates (Ex. x509 certs), smart cards, cardspace, etc...
Domain/IP restrictions: In this case, only clients coming from trusted/verifiable domains; such as internal subnets; are allowed into the admin area. Remote admins often go through trusted VPN entrypoints so their session would be verifiable and is often protected with RSA keys as well. If you're using ASP.NET you can easily perform these checks in the HTTP Pipeline via HTTP Modules which will prevent your application from ever receiving any requests if security checks are not satisfied.
Locked down IPrincipal & Principal-based Authorization: Creating custom Principles is a common practice, although a common mistake is making them modifiable and/or rights enumerable. Although its not just an admin issue, it's more important since here is where users are likely to have elevated rights. Be sure they're immutable and not enumerable. Additionally, make sure all assessments for Authorization are made based on the Principal.
Federate Rights Elevation: When any account receives a select number of rights, all the admins and the security officer are immediately notified via email. This makes sure that if an attacker elevates rights we know right away. These rights generally revolve around priviledged rights, rights to see privacy protected information, and/or financial information (e.g. credit cards).
Issue rights sparingly, even to Admins: Finally, and this can be a bit more advanced for some shops. Authorization rights should be as discreet as possible and should surround real functional behaviours. Typical Role-Based Security (RBS) approaches tend to have a Group mentality. From a security perspective this is not the best pattern. Instead of 'Groups' like 'User Manager', try breaking it down further (Ex. Create User, Authorize User, Elevate/Revoke access rights, etc...). This can have a little more overhead in terms of administration, but this gives you the flexibility to only assign rights that are actually needed by the larger admin group. If access is compromised at least they may not get all rights. I like to wrap this in Code Access Security (CAS) permissions supported by .NET and Java, but that is beyond the scope of this answer. One more thing... in one app, admins cannot manage change other admin accounts, or make a users an admin. That can only be done via a locked down client which only a couple people can access.
If the website requires a login for both regular activities and admins, e.g. a forum, I'd use separate logins which use the same user database. This ensures that XSRF and session-stealing won't allow the attacker to access administrative areas.
Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.
Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).
A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.
I reject obscurity
Using two authentication systems instead of one is overkill
The artificial pause between attempts should be done for users too
Blocking IPs of failed attempts should be done for users too
Strong passwords should be used by users too
If you consider captchas ok, guess what, you could use them for users too
Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".
If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.
So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.
Have a good admin password.
Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".
Add a pause for each password check to prevent brute force attack.
Here are some other things to consider:
One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.
We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.
The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).
If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.
Naturally the editing stage should only be available on a local intranet and/or using a VPN.
This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.
Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.
It very much depends on what kind of data you want to protect (legal requirements and such).
Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)
Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.
I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.
Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.
Perhaps you could always put the administration section in a big directory, e.g.
http://domain.com/sub/sub/sub/sub/sub/index.php
But that's not really good hah.
Perhaps you could include a query string in the home page, like:
http://domain.com/index.php?display=true
When it does, the username and password field will appear.
I am considering adding OpenID to our customer facing admin and control panel areas...
1 - Associating OpenID's With Existing Accounts
For customers that already have accounts with us, I'm thinking they would need to login using their existing account number that we issue and then I'd have a mechanism to associate their OpenID with that account in their account management area (call it 'OpenID Manager' for the sake of argument).
In the 'OpenID Manager', presuming the user already has an OpenID, would I authenticate the user against their OpenID then associate with our generated account number for future OpenID logins (assuming that they authenticated ok)?
2 - Sensitive Data
Although we don't store full credit card data in our DB there is other data that is sensitive, invoices, domain reg details etc. After reading this article http://idcorner.org/2007/08/22/the-problems-with-openid/ I'm a little cautious about the idea of using OpenID in this way, what's the general consensus with you folks?
It seems to me that a lot of the arguments against OpenID are either made out of ignorance or by people with an axe to grind.
For example, the document you link to complains that identifying yourself with a URI is "dehumanising and more than a little frightening". Is that a legitimate complaint, or something written by somebody desperate to find things to complain about?
The two major things that get brought up are phishing and compromised accounts and these arguments have been rehashed so many times, it's hard to take somebody seriously if they bring them up yet again with no new points to make.
Phishing protection depends on the provider. Some providers offer much better security than typical websites ever would. Some providers just offer the typical username and password. Either way, if an account is compromised, that's something between the user and their provider, it's not your concern. You don't worry that the end-user has a keylogger installed on their computer, do you? That's because their local security isn't your responsibility, even though it might be used to gain access to their account. Likewise with OpenID - its security is not your responsibility.
If you compromise an OpenID, it gives you access to more than a single website. Sure, but the same is true for email. Just say you've forgotten your password, and you get sent a new one. You now have access to every account they've registered with that email address.
OpenID is no worse than the status quo, and it's significantly better in many circumstances, especially for informed users. If you are still wary of it, then just make it optional, so only the informed users use it.
I'd allow the registration of multiple OpenIDs with a particular account. That's a nice feature to have because it allows users to migrate between OpenIDs should the need ever arise.
That said, the idcorner link raises a good point. I think he massively overblows the security issue and makes many idiotic assumptions about how OpenID providers work, but that OpenID really isn't intended to replace all forms of user authentication. It's designed to make it easy for "drive-by" users to interact with a site with some form of basic authentication.
Ever been to somebody's blog, want to post a comment, but first you have to step through a 3-page registration? OpenID solves that problem.
Want to post a quick bug report on a public tracker but need an account first? OpenID to the rescue.
Want to store sensitive proprietary data in a web-accessible way and provide access only to people who are trusted? OpenID is not the solution.