I am trying to make a web app that uses PlayFramework2 and Neo4j Graph Database.My web app going to include user system.Users can add their visited places as nodes and traverse.My question; is it okay for keeping passwords and other personal information in nodes for authentication or using table based another database is better for login to web app.If all work can be done using Neo4j, what should be the structure of the user system in graph database for security.I am newbie at these jobs so, sorry if it is a absurd question.
Of course you can use neo4j to store user information.
As on all databases, be careful with some data, don't store password without a hash/crypt method !
If your datas are sensible, you should well configure your neo4j instance to not allow remote connection, and why not implement some user role for connection.
See here : http://docs.neo4j.org/chunked/stable/security-server.html
You should either use one of the modern auth mechanisms like OAuth2 or at least strongly hash and salt the passwords with a long salt.
Related
This is my first question, so I hope I don't miss a thing. To be clear from the start: I don't expect an answer which dives deep into detail. This is just about getting a general understanding of how to work with this kind of software.
So I don't know if "Identity Management System" is a suitable term for what I mean but when I talk about Identity Management Systems I think of something like Azure AD, which as far as I know provides e.g. web developers the possibility to integrate a way users can authenticate (including access privilege etc.) on their website.
What I'm quite unsure about is how to work with/ integrate such tools in a project. I will try to make it clear with an example: Assuming I have a website let's say this website is a blog. The blog consist of different posts which are stored in my own database which is connected to the website. The posts are written by different users which authenticate with a tool like Azure AD. The user's data is stored somewhere on a server run by e.g. Microsoft. If I want to display the posts togethere with the name, email.... of the user who wrote them, how would I do this?
Is it possible to query the user's data directly from the Identity Management System and display it? This does not sound ideal to me as the consequence would be that data the website uses is stored in two different locations.
Would you kind of copy the user's data from the Identity Management System to the websites database and query it from there? This does not sound like a good solution either because then data would be duplicated.
So whats the "right workflow"?
I appreciate any hints and further information I can get:-)
AFAIK To get the user's information like name, email etc. you can add these claims while generating the JWT token.
To generate access token, you have multiple authentication flows such as Authorization code flow, ROPC flow, Implicit flow.
To add the claims that you need to return with the token, you can make settings like below:
Go to Azure Portal -> Azure Active Directory -> App Registrations -> Your app -> Token configuration -> Add optional claims
When you decode the token via JSON Web Tokens - jwt.io you can find the user information that you need.
To know how to generate access token, you can refer SO Thread which I solved it before.
For my Next Project (web + electron + ionic),
I want to use angularjs but don't want to use nodejs and for database.
I am thinking about pouchdb or google-firebase.
Now security is an issue for my database. like i have to connect with my database using angular because i will not use nodejs.
So i have to put my username and password on connection.
will my username and password secure ?
I am thinking that anyone who press Ctrl+u or from dev tool can see my user access.
Any suggestions ?
try angularfire2 library for firebase using this library no needed nodejs or any backend server. it's directly communicate with firebase.here is library
https://github.com/angular/angularfire2
I am afraid that you can't do that, you need some server side application to connect with the database in a secure way.
There is some gold rules you must always follow:
There is no security from the client side.
Never trust on information that comes from the client, even if you think it's validated.
For the security purpose, you can go with firebase auth
these are many secure login methods like
-FirebaseUI
-Password-Based
-Facebook
-Google.. etc
reference link- https://firebase.google.com/docs/auth/web/start
If you are planning to use firebase for the huge database then one thing keep in mind firebase is not designed for the huge database it's limited.You can't compare firebase to SQL n MySQL etc databases. Firebase specifically designed for small databases.
If you grant write access for your chat clients by one hardcoded credentials (really easily get known) - you are on very dangerous side: one can quickly fill your DB with tons of garbage. There is no harm to hardcode read credentials (in order to separate access to different server DBs, i.e.) but for write ones you definitely need registration, which means Node or something. It will handle new users creation and give you ability to block unwanted client behaviour, just in case.
So from what I have read on IdentityServer I should be storing details about the user such as first name and last name inside claims. How would a web application then be able to access the claim information? Since the User Info endpoint requires a valid access token representing the user, I suppose I would need to make an API that could access that returned the profile information of other users? Is this the right way to do it? (use case, web page needs to display contact details that are stored in claims of another user)
Also what would be the way for multiple language profile information be stored and retrieved in the claims? For example a user can have a name/title in multiple languages. I'm thinking of making [LanguageCode]_[ClaimType] (fr_first_name) naming convention and either adding all languages to just the profile IdentityResource or creating separate resources per language.
Your best bet is to set up a project using the IdentityServer4 QuickstartUI example and review that code to better understand how it all works. As of version 4, Identity Server is only focused on the sign-in / sign-out process and the various flows around authentication. They also provide a basic EF-driven persistence model, and they also support the ASP.NET Core Identity persistence model (also EF-driven), but both of those are not meant to be production-ready code.
Basically, persistence of user details is considered your responsibility. That being said, the cookies used for ASP.NET Core authentication greatly restricts how much data you can/should store as claims. The best model is to keep "real" identity provider (IDP) claims as claims, don't add new claims to that list, copy what you need into some other separate user-data table you manage completely, and use the unique claims identifier (almost always "subject id") as the key to your user data. This also makes it easier to migrate a user to another IDP (for example, you'll know user details for "Bob" but he can re-associate his user data away from his Facebook OIDC auth to his Google auth).
Basic persistence isn't too difficult (it's only 12 or 13 SQL statements) but it's a lot more than will fit in a Stackoverflow answer. I blogged about a non-EF approach here -- also not production-ready code (for example, it has ad-hoc SQL to keep things simple), but it should get you started.
I have a Two Factor Authentication system where I need to store the Auto generated Code and the requested time in some form storage for retrieving it later purpose. I need to know what is the best way to store these sensitive information.
I was planning to use Session to store those sensitive information. When I googled, In some places people are telling its not recommended to use session to store sensitive information. Can any body explain why so.
Any suggestion to this will be highly appreciated.
Thanks
In your user database is fine, it's a web app so the database should be completely hidden from end users (if properly managed).
The rest is just making sure your actual application is secure -- ie no SQL injections, no buffer overflows, proper workflows that all pass through your server side authentication engine etc.
If you are worried about your information they should be encrypted before store them in database, for more secure propose you can use HSM (Hardware security module) to do encryption and decryption for you or even you can rely on OTP (one-time password) for two factor authentication.
What's the best practice or the common way of keeping (or not keeping) Evernote users in your application's database?
Should I create my own membership system and create a connection to Evernote accounts?
Should I store Evernote user data (or only part of it) in my own app and let the user log in only with Evernote?
Summary: you must protect their data but how you protect it is up to you. Use the integer edam_userId to identify data.
I think the API License agreement covers protection in the terms:
you agree that when using the API you will not, directly or indirectly, take or enable another to take any of the following actions:...
1.8.4 circumvent or modify any Keys or other security mechanism employed by Evernote or the API;
If you cache people's data and your server-based app lacks security to prevent people looking at other's data, then I think you're pretty clearly violating that clause. I think it's quite elegantly written!
Couple that with the responsibility clause 1.2
You are fully responsible for all activities that occur using your Keys, regardless of whether such activities are undertaken by you or a third party.
So if you don't protect someone's cached data and another user is able to get at it, you're explicitly liable.
Having cleared up the question of your obligations to (as you'd expect) protect people's data, the question is how do you store it?
Clause 4.3 covers identifiers pretty directly although it's a bit out of date now that we are all forced to use oAuth - there are no passwords ever entered into anything other a web view. However, mobile or desktop client apps must provide a mechanism for the user to log out, which must completely remove the username and password from your application and its persistent storage.
For a web app, you can't even save the username: If your Application runs as an Internet service on a multi-user server, you must not ask for, view, store or cache the sign-in name or password of Evernote user accounts.
The good news is that you can rely on the edam_userId value which comes back to you in the oAuth token credentials response, as discussed here.
When you look at the Data Model, you can see the unique id under the User and going into the User struct, see the reassuring definition The unique numeric identifier for the account, which will not change for the lifetime of the account.
Thinking about the consequences, as you can't get the user id until you have logged into the service, if you want to provide a local login for people you will have to link your local credentials to the user id. That may irk some people if they have to enter a username twice but can't be helped.
You can allow users to log-in via OAuth. Here's a guide on how that process works.
But you'll probably also want to store a minimal amount of user data, at least a unique identifier, in your database so you can do things like create relationships between the user and their notebooks and tags. Refer to the Evernote data model for those relationships. If you're using rails, this will also help you take advantage of rails conventions.