I'm integrating with react-native-keychain and I'm somewhat confused about the setGenericPassword and getGenericPassword methods. What exactly is the difference between username and password for the setGenericPassword(username, password, ...) method when to access the stored information we simply call getGenericPassword without any parameters.
Is the password even doing anything or is the entire point just to store two strings? Is this where the sensitive data should be stored? I've read the API description and looked over the example repository but it wasn't clear to me.
Related
I was wondering how secure this would be. I don't have full code for it right now, but I'll try to explain it in words.
When a login button is clicked, using socket.io, the username and password will be sent to a Node Js server. Once the server receives the username and password, it will check a text file, to see if there is a username and password that matches. If there is, the user data will be sent back.
Is there any way that someone could access the text file without direct access to the server? Would this be secure in general?
this will surely get closed as not a coding question, but I will answer anyway.
So you intend to include the user name and password with every request? THats a lot of repeated authentication, use a JWT instead. Use a well known library for auth (like auth0). If you want to make your own mAke sure you send it over https.
Can somebody read the text file?
Well
do NOT store the password, stored a salted hash. This is not reversible so even if the text file gets stolen it doesnt have the password
in theory nobody cam get at the file. In practice there is a huge gap between theory and practice. All the password breaches you hear about are 'bad guys' accessing a file /db that nobody thought could be got at
one question, maybe it's a bit longer, but i really hope someone can help me 🙏
I've been reading the docs but simply can't figure it out.
Is there a way i can create a signup feature where user creates an account (only simple one, email and pw) , and that account data is saved somewhere in a json file
And then the user can login via post method by typing his credntials.
And if credentials are correct (out of any other credentials there are in that particular json file) he gets a random jwt.
I mean i know i need to set up the rules if email and pw match any user and pw from the json file
Thanks!
Mockoon offers mostly stateless and independant endpoints mocking. Which means, there is currently no easy way to "code" it for such advanced use cases.
You can simulate a POST /signup and POST /login call, make sure the request looks OK by using Mockoon's rules, but they will not be linked and the credentials will not be persisted.
A system of CRUD endpoints is currently under development but it will allow for JSON manipulation only, not the kind of behavior you describe which is also very close to a production application.
There is a common requirement of storing user credentials securely (user id / user password) in the App and use them automatically next time the App starts, but I'm not being able to figure out how to do this without user interaction.
Using JSON Store I need a password to encrypt the information, so if I store user credentials in the JSON Store I will need to ask to the user for the password used to encrypt the information.
A solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
As explained in the comments this is a really bad idea.
Is there any solution to store user credentials securely and recover them without user interaction?
You can use the Keychain API on iOS. Android doesn't seem to have an equivalent API.
The most complete solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
I would strongly advise against doing that, if you store the encryption key (the user id) in plain text, then the attacker can simply use that to get to the password.
Update (Aug 27, 2014)
You should consider:
Hashing - You could hash values you want to protect. These are one-way functions, so you can't get the password back once you hash it. However, you can verify that the user provided the correct password. For example: First login you store( hash(password) ) then on next logins you compare if hash(password_provided) == stored_password_hash. If it matches, the user provided the same password. You should also use a salt.
You could give the user the ability set a pin using some library like ABPadLockScreen (you could probably find or implement something similar for Android too). You can then use the pin as the PBKDF2 input to generate an encryption key (JSONStore will do this for you when you pass the pin as the password). I would advise in favor of letting users only try a small amount of incorrect pin numbers, especially if the pin is only numeric and short, that way they can't easily guess the pin by trying various combinations. The idea here is that a pin will be easier to remember and type than their password.
FYI - There's a Stack Exchange site similar to StackOverflow but for security questions here.
Is it any safer to create a table holding user information and another one for their passwords than using the same table for everything?
No I would just do this:
id, username, password.
Where id is just autoincrement, username is a varchar of 20 (or so, depending on your needs) and password is an MD5 or SHA1 hashed password with a salt.
Using two tables for this just doesn't make sense. Then you need to work with joins to get the data. And that's just an unnecessary burden.
No, I cannot see how that can make it safer.
You should actually refrain from storing passwords at all. Just store their salted hash.
Further reading:
Stack Overflow: Preferred Method of Storing Passwords In Database
I disagree with other people - put the authentication information in a separate table and to the greatest extent possible pull authentication out of your application entirely. You shouldn't care. Think siteminder and the like - your web application doesn't have any information about how the user is authenticated. Password, smart card, etc. (Same thing with Kerberos or Active Directory on desktop applications.)
This approach even works if you use a framework like Spring Security. Just set up your interceptor so it looks at the authentication tables alone. You could even use separate DataSources so your interceptor can't see application data or vice versa.
Obviously your application will still need to manage information about the user's authorizations, something usually handled in a 'roles' table. But there's no need to for it to know how the user was authenticated.
i think having the username and password in the same table is ok ,
but also l have seen people doing silly stuff especially when working with the ORM , someone might end up exposing password hashes etc
for example entity framework C#
someone can just do
appcontext.Users.ToList();
no attributes kept ensuring that password is hidden nor DTOs (Data Transfer Object) ,
upon noticing this l just keep another authentication table and the other thing l there are a lot of fields for forgot password, last password change all those fields l will have them in another table with the password
No it is not safer. Just make sure your passwords are Salted+Hashed before you stored them in the DB.
No. Not unless each table required a different user account to access it - which would make querying it a complete pain - and even then, the hacker has worked out one login, so chances are they can get the other.
Just make sure that you are storing passwords in a hashed form, using a secure hash like SHA-2 and a salt. Do not store them in plain text and (IMHO) don't store them encrypted.
Btw, there is already a pretty simple (and powerful) c# salted hash class library (they've also included a small demonstration of how to use the library) out there - Link .
It also provides a verification mechanism (so you can verify the user's input as a valid password) and you can choose the Hash algorithm yourself (Sha1/MD5/etc.)
There is no security benefit, but using multiple tables can be useful for storing credentials to multiple systems tied to a single login.
As mentioned above, security should be provided by salted hash for passwords.
Creating a API here and I want people to be able to make simple mobile apps that could get the username/password of my users and of they go to interact with my server. So I need to have a Basic Auth(OAuth and other stuff are also going to be supported, mostly for a different use case). Right now I have a example from a Book saying i could just receive the (unencrypted) password as part of the post and looking at successful APIs I see that twitters gets unencrypted passwords on the headers of their HTTP request.
Another options would be to get md5 or SHA1 hashes, but without a secret salt, this seems like an exercise in futility. I asked a couple of people and everyone had a different(strong and heuristic) point of view, so....
What is the best way to get passwords for basic auth in a API and why?
Uh, do not give out the passwords of your users to other apps. Or via your API. Or ever. They should be stored 1-way anyway (i.e. hashed).
But I'm not so sure if that is what you are saying. You talk about OAuth (which you can use to generate tokens that let API's access various components of your system, because the user says that it is possible).
For example, say you wish to allow API-users to query a certain users properties (say, their location), then you create a token for this access via OAuth, and the API-caller passes that. At least, this is my understanding of the model. Obviously, you should review OAuths webside, and find an appropriate implementation for your given language.