I'm trying to make a login screen with following properties:
Left pane: button to choose an access database (open file).
as soon as the "connect" button is pressed, the right pane opens with a user/password screen.
The user and password should be checked in the access database users table.
The database is only loaded if correct credentials from inside the file are provided.
So in short:
Is this possible or do i need a separate file to store those credentials and how to load the database in order to access it in my software.
I'm a beginner.
thanks in advance
The trick is you must open the database in order read the credentials. Therefore you need two layers of security.
The good news is MS Access supports this. You can set a password on the database file itself, and then distribute that password with your app in a place where the user can't see.
The bad news is these passwords aren't all that secure. First, securely distributing a credential with your app so it can't be discovered is surprising difficult. In short, it's something you should not be attempting as a beginner. Second, the MS Access password protection feature is not all that strong.
Most systems where security really matters will keep the credentials and most important data on a system they control, usually via a web service.
If you do proceed with the Access database, make sure you understand the correct way to store user passwords... namely that you don't ever store the password itself, but instead only keep a cryptographic hash. When a user logs in, you also hash the attempted password and then compare the hashes.
Related
Should I have one login form for ordinary user and admin
Or
should I have separate login form for admin and ordinary user?
It is OK to have the same form.
The purpose of the login page is authentication-- determine who the user is, not what they can do (see What is the difference between authentication and authorization?). So for example you might want them to submit a password or other token to reduce the risk that they are not the person they say they are. That can be the same process for everyone.
Certain features in your site may be available only to administrators or end users, but checking for permissions (authorization) can only be done after you're sure who the user is (they have authenticated). And logic to check for permissions should be present on every single page. So it has little bearing on what the authentication process is like.
You should just use one form for both admins and ordinary users if the log in information required is the same. Having two forms only makes the application more complicated to write. Having one or two login forms would be equally safe. Just remember to implement the correct security measures on the server side so a user does not get admin privileges.
The first step in authentication would be to check if the username exists, then check if the entered password matches the user's password in the database (passwords should be hashed). Then you can do authorization to check if the user is an admin.
While this seems to be asked in the form of an opinion, it makes more sense to answer this based on what most websites (or applications) do.
It really depends on the context. As a general rule, the same login form would be used for regular users and admin users. Generally, a parameter specifying whether the user is an admin would be stored in a database table for the users. The authentication method(s) that are executed upon clicking the login button will verify the user exists, check the password against the hash, then check the database table to see if the user is an administrator.
In some certain circumstances, I have seen a separate login page for administrators, but it is rare. One example might be a webstore that has an administration/management dashboard which is separate from the main site. Generally, though, these will work via the same form.
I apologies in advance - for this question needs a bit of background, which is likely to be long winded:
I'm trying to build an app which works offline with PouchDb. PouchDb will sync with Cloudant.
Technologies used:
Hapi, SQL, Vue, Cloudant, PouchDb
I have built a little hapi.js service to sign up / authenticate users. When an "account owner" signs up - they are added as a new user to a SQL database.
Using Cloudants API, I provision a new database (with a random name), and set security on the database so the new user has access.
I save the security (DB name, User name, and password) as metadata back to the user in the SQL database.
A very similar approach to here: https://www.bennadel.com/blog/3208-provisioning-cloudant-couchdb-databases-from-auth0-for-a-database-per-user-architecture-in-angular-2-4-1.htm (indeed, I based the above on this).
When the "account owner" logs in, the SQL DB is queried - the MetaData retrieved and sent down to the client side vue app. The PouchDB remote string is then populated with the Cloudant DB name, User name, and password.
eg:
const remoteDB = new PouchDB(`https://${name}:${pass}#0000-0000-bluemix.cloudant.com/${DBname}`);
This all works: PouchDB can talk to Cloudant - and data is going to and from without issue.
The "Account owner" is able to give read/write access to other people ("Staff") to their cloudantDB. When they add a new Staff Member, the Staff Member is added to the SQL DB. Using cloudants API, I create new security credentials for this user so that they can access the DB- (I do NOT create a new DB) and save them to the Staff Member in the SQL db as metadata...
The new staff member is sent an email - they set their username and password on the SQL db, and can log in. The Cloudant meta stuff is picked up... etc etc... PouchDB / Couchdb talks to each other - this also works.
Initially I was a bit concerned about sending this meta / credentials down to the client - I wanted to use a JWT or something... But then I saw this answer to another question:
https://stackoverflow.com/a/30417620/714950
So passing credentials down seems to be how its done in Pouch/Couch/Cloudant etc. I've got to be honest - I find the whole thing works like 'magic' - like its too good to be true, and that worries me a bit as I don't really understand it. I might be doing something terribly wrong.
Now for my question(s):
I'm passing these credentials down - is this safe? How would I reset / time out the username and password.
When they log out, I wipe the data from Pouch?
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data? so I guess I would need to persist the data in Pouch for when they log in again?
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
I'm also unsure how I validate the data... making sure that which gets saved to the DB is valid etc...
I suppose I'm just trying to get my head around this - I've been googling and reading everything I can, but it doesn't quite answer my questions.
Thanks
[** Just had a thought...
Thinking about it, I don't actually need to create the staff user within the SQL DB.
The Account Owner is set up - the DB is created in Cloudant, and credentials applied.
Not just had a thought: Theoretically, when a staff member is added - I only need to set them up inside Cloudant, and write their ID to the "Account Owner" as meta data so that they can be removed etc.
This way, a staff member could log in directly to the Cloudant DB.
However, I generate the security credentials using Cloudants API - so the staff member won't know what their username and password is. I don't want to send the username and password in an email.
Is there a way I can handle this? Am I able to specify a username and password when creating the security credentials? How do I handle things like password resets on cloudant?]
Thanks
I'm passing these credentials down - is this safe?
If your site is served out over HTTPS, then a bad actor would find it difficult to glean the Cloudant username & password in flight. Your client-side app needs to retain the credentials for your app to be "logged in" (for it to retain the right to sync with the server). I like to retain the data in a PouchDB document (e.g. _local/auth - local documents are not replicated so reside only on the device you create them on). You are right to be concerned, however, about having database credentials floating about on a client-side computer. Some folks decide that that is not acceptable and implement their own middle layer. If you don't need sync (that is data can be altered at both client and server side), you might use PouchDB as a buffer for unsynced data and push it to your own API when you're online. You can then control authentication, timeout and access to the database from your own server-side code.
How would I reset / time out the username and password.
You can "log out" by:
deleting your client-side state e.g. deleting the _local/auth document.
making the key/password have no permissions on the client side. Without _reader/_writer/_replicator rights, a Cloudant api key and password is useless
Alternatively you could transmit the username & password to the client which could use them against the Cloudant POST /_session endpoint which gives the web browser a time-limited cookie. Your app could then "forget" the credentials until it needs them again.
When they log out, I wipe the data from Pouch?
Yes.
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If you write your client side app correctly, it could function perfectly well with its local PouchDB data, whether it has an internet connection or not. This is known as an Offline First approach. As long as your credentials are still valid, your app can sync when a connection is re-established.
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data?
Correct. If you have only one copy of some data and delete it, you lose data :)
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
Correct. On a shared computer, another user's data may be visible to the second user. Just as if I left my Facebook session logged in on a shared computer.
Is it possible that a website uses the models of another lavarel website to access the database, without the first website having the sql credentials hardcoded. But with the credentials to log into the second lavarel website hardcoded.
This way the first website doesn't have to have the sql credentials on it's ftp server, but can still access the databases through the other website (with their personal login of that website).
If that is impossible, I am wondering, is there a way to access a databases without having to hardcode the credentials anywhere.
UPDATE (the actual problem)
Only a part of the database should be visible to a particular user, so i can provide different users with different credentials and they all see something different in the database
What you are talking about is an API. So you'd build out the entire infrastructure on the first website, then on the second website, it would make some kind of calls to the first website to get back the information it needs, usually using some kind of credentials or access token.
This way, you can allow anyone in the world to communicate with your website, kind of like how Facebook, or Twitter does.
As far as accessing your database, you would need to tell your app somewhere the credentials to use, so technically, you do need to hardcode them somewhere as they can't just magically make up some credentials somehow to access a database.
if your different users are defined:
use laravel model/db event to replicate the data to a database by
user.
Or sync each database with a cron job..
These have benefits to avoid security transport problems.
My goal is to be able to read one database without having to authenticate the user, authentication for editing this database should be required. All other databases should only be read/writeable for valid users. And I don't want having to set it for every database I create in the future, authentication required for read/write required should be the default.
I thought I could do this by setting require_valid_user to true, but now CouchDB always asks for username and password, so I need a way to exclude one database. This database should be readable for public and writeable for valid users then.
I get around this problem by authenticating all users through one single database (i.e. /login). That database is public, and contains a design document with an HTML file as an attachment. The user is served this file, fills out their credentials on a form, and I use jQuery.couch.js to authenticate and store a cookie in their browser. Once they've got a valid login, I inspect the userCtx object to check their role, and redirect them to the appropriate database.
It's a hack, but until CouchDB is able to serve a login page instead of a JSON error message whenever you're not logged into a database, it's the only reliable method I've found.
Make sure to protect your public login database with a validate_doc_update key in the design document, so nobody but admins can overwrite anything in it.
Hope this helps.
i have to create a login module (The question is not language specific) but i am not sure how will i validate the user. Where and how will i store the passwords. Will i have to encrypt and decrypt my passwords and if yes what are the best suggested way to do them. Overall i need to know what all things i need to take care of for developing a login module where a user can login securely to access my site.
You don't need to decrypt your passwords in order to validate them, just one way encryption works fine for this. The idea is that when a user enters a password, you encrypt it the same way (using the same algorithm and "salt") and then compare with the encrypted one stored in your database. If they are equal, with a great probability it means it's the same original password. Thus you prevent anyone - the adminstrator or any attacker - from knowing the original passwords users use on your web site.
As for the rest, it's very simple, you have a table in your database which contains user logins, encrypted passwords, and possibly some profile information as well (full name, etc).
I usually use the following function to hash user passwords:
$password_hash = sha1(MY_SALT_1 . $login_name . MY_SALT_2 .
$password . MY_SALT_3);
where MY_SALT_* are arbitrary predefined strings, could be e.g. 'the dark', 'side of', 'the moon' (or actually the less related - the better).
Yes.Sure you need to encrypt users passwords.Because most of the users using the same password almost all sites.At that time they are not want to show the passwords to admin.And another reason is most of the time the site DB may be accessed not only by admin.Some other technical persons in the organization.So it is better to encrypt the password.SHA1 is the best way to make the encryption.
Where and how will i store the passwords.
I am not sure what you mean by this.Every one use the database for it like phpmyadmin.