I would like to make an auth page to my website with only a Key field.
Example : I give an Key like 'A5DP7123OAC' to my customer for the login.
And if the code is correct he can access to his panel. Actually I just create a Cookie :
withCookie(cookie()->forever('access', 'true'));
But it's not a good way I think.
Do you have solution to Auth an user only with a Key ?
Thank's
You could pass your key to the session and then check to see if the key the user provides matches the key in the session. If so you can log the user in manually using one of the methods found here: https://laravel.com/docs/5.2/authentication#other-authentication-methods
If you don't want to use the session, you could also create a DB table and store your keys there optionally giving them expirations so that the keys are only valid for a period of time. You could also make it so that keys are only valid for one IP address. Plenty of options.
Related
I am working on a function that allows a user to check if their existing device contacts are using our platform, based on phone numbers.
For privacy and security, we are hashing the user's contact's phone numbers on device (salted with the user's id) before sending to our server.
Server side, we then need to hash our entire contacts table (using the user's id as a salt), which is currently being done in a for loop.
We then check this list against the request list, and return the details for any matches.
However, I'm sure there is a more efficient way of doing this, something like computing the hash in a calculated field then including the $request->hashes in a "whereIn" clause.
Could someone give me a pointer on the best approach to be taking here?
The question is, what privacy and security are you achieving by sending hashed value of contact number?
You are hasing the contact in client side(device), that means you are using a key and salt that is available in clinet side already. How can that be a security feature?
If you want to search hashed value in database then it's better to save hashed contract number in a column in the first place. So you can directly run where query in database table.
Ideally, if you really concern about user's contact number you should:
Encrypt the user's contacts in backend/databse not in frontend.
If you need to query for a field in database then you should make a hash valued column that can be matched easily. I mean searchable fields should be hashed so you can run direct query.
Nothing to worry about user's contact security in frontend if you are already passing it trhough Secure HTTP(HTTPS).
Even it a common practice in the industry, to pass a submitted plain password via HTTPS when a user submit it in frontend. It shouln't be a concern of privacy or security.
Since my 2 post about the LDAP Authentication (first post, second post), we created our own custom authentication scheme and function to connect to the application using our Active Directory credentials.
We can successfully log in the application. However, we have a second function which retrieves the group of the user in the AD. Here's the code when I'm trying to retrieve the group into a Text Field (P1_GROUP) :
ourschema.ldap_get_group_apex_from_user(
p_username => v('APP_USER'),
p_password => 'thepassword')
As you can see, this is working, because the password is in static text. This leads me to my main question :
How to retrieve the user's password in Oracle Apex, and what is the most secure way ?
I tried to set a Branch or a Process in the Log-In page while redirecting the user's the the home page, and Set Value of the :P9999_PASSWORD field to the home page text field P1_PWD.
So, I tried to adapt my code with the text field
ourschema.ldap_get_group_apex_from_user(
p_username => v('APP_USER'),
p_password => :P1_PWD)
Unfortunately, this doesn't seems secure because the password would be visible in the HTML code of the page (right click + inspect and there it is. Moreover, sometimes it gives me an error
Error computing item source value for page item P1_GROUP
It seems like the application cannot execute the function because the password is still not initialized.
Is there a way to retrieve :P9999_PASSWORD or to transfer it from the login page to a global variable/global page or a text field ? Or is there a function to retrieve the current user's password ?
Thank you again for your time, do not hesitate to ask for more details as this is a very specific case,
Thomas
I don't think your approach is correct. Ideally, even an administrator of your system should not be able to decrypt a user's passwords; they should be stored as hashes.
You're trying to look up the user's group memberships? You don't need the user's own credentials to do that. Use a dedicated account that has access to your Active Directory system and store that password encrypted in your database. Use that account to search for and look up the user's group memberships. That way, even if your system is compromised, only that account is exposed.
Thank you all for your answers and your advices on my case, and for taking the time to help.
We found a solution that we think is reliable, here's what we did if that could help other people.
We created a global variable G_GROUP, which will receive the group of the user
On the login page, we created a process before the login process.
Set the Source of the Process to PL/SQL Code :
:G_GROUP := pdbadmin.ldap_get_group_apex_from_user( --our custom function to retrieve groups
p_username => :P9999_USERNAME,
p_password => :P9999_PASSWORD); -- the function get the username and password in the fields
If i want to display the group of the user in the main page, let's create a Text Field P1_GROUP which as for Source the PL/SQL Expression :G_GROUP
Our group is initialized, and the password is not shown in any field.
Let me know what you think about it, and if you guys think this could be improved.
What is the recommended way to store user settings in Parse Cloud?
I've two approaches of which I don't know which one is best suitable for a scalable app or if there is a better way of doing this.
The first approach is to create a class with all settings for each user and have a relation between the user and the setting.
The other approach is to simply store the settings for each user in a user object. I feel the second approach is the better one.
I've had a look at PFInstallation but not entirely sure if that can be used to set User Settings or if the use case is for push notifications only.
Both of your solutions:
an associated class to hold user settings
store attributes directly in the user class
Are valid.
The advantage of #1 is that it will be easier to secure the settings. In the case of #1, you can create an ACL when you create each user's setting object that will allow only the user associated with that record to read, edit or delete the settings object.
In the case of #2, if any of the fields are sensitive, then you'll need to explicitly protect those fields using the userSensitiveFields config key to ensure that they are not returned when user records are queried.
What is the best way to securely login in a user and keep the user signed in with cookies and sessions?
For example:
Check if password and email are valid for a specific user
Set a cookie with arbitrary string
Create a session with the same arbitrary string
Validate each request by the user by making sure the arbitrary strings of the cookie and session are the same
What is the best way to securly login in a user and keep the user signed in with cookies and sessions?
Using an established library.
It depends on how you define "create a session". For our purposes here let's define this as "create a server-side data store with an id and set a cookie with that id"; i.e. what the default session_start() does. Then:
Ensure the connection is HTTPS.
Check login credentials.
If valid, create a session (see above) with a large, (pseudo-)random id and an expiration time as short as possible but as long as necessary. Security here comes from the fact that it's infeasible to guess suitably random session ids, so the longer they are and the shorter their window of validity is the better.
Store the id of the logged in user in the session.
On each page request, see if the session with the id from the cookie exists; if so, use the user id stored in it to get your logged in user.
Optionally storing and checking the user agent is not a bad idea; you should not check the IP address though, as that may change legitimately.
Apart from storing it in sessions , you can also follow this method for keeping an user logged in , even after he closes the browser ->
1) Create a cookie storing user details and an unique hash
2) Create a sessions table (in a mysql db or any other db of your choice) where the unique hash is stored against the user-id, and the user agent of the browser,and the ip address .
3) Next time when the user logs in check that when the user logs in , is it from the same ip,same user agent .. If not , then delete the database entry , and repeat steps 1 and 2.
Apart from keeping an user logged in , it also gives you better security than just storing in sessions.
I'm building off of a previous discussion I had with Jon Skeet.
The gist of my scenario is as follows:
Client application has the ability to create new 'PlaylistItem' objects which need to be persisted in a database.
Use case requires the PlaylistItem to be created in such a way that the client does not have to wait on a response from the server before displaying the PlaylistItem.
Client generates a UUID for PlaylistItem, shows the PlaylistItem in the client and then issue a save command to the server.
At this point, I understand that it would be bad practice to use the UUID generated by the client as the object's PK in my database. The reason for this is that a malicious user could modify the generated UUID and force PK collisions on my DB.
To mitigate any damages which would be incurred from forcing a PK collision on PlaylistItem, I chose to define the PK as a composite of two IDs - the client-generated UUID and a server-generated GUID. The server-generated GUID is the PlaylistItem's Playlist's ID.
Now, I have been using this solution for a while, but I don't understand why/believe my solution is any better than simply trusting the client ID. If the user is able to force a PK collison with another user's PlaylistItem objects then I think I should assume they could also provide that user's PlaylistId. They could still force collisons.
So... yeah. What's the proper way of doing something like this? Allow the client to create a UUID, server gives a thumbs up/down when successfully saved. If a collision is found, revert the client changes and notify of collison detected?
You can trust a client generated UUID or similar global unique identifier on the server. Just do it sensibly.
Most of your tables/collections will also hold a userId or be able to associate themselves with a userId through a FK.
If you're doing an insert and a malicious user uses an existing key then the insert will fail because the record/document already exists.
If you're doing an update then you should validate that the logged in user owns that record or is authorized (e.g. admin user) to update it. If pure ownership is being enforced (i.e. no admin user scenario) then your where clause in locating the record/document would include both the Id and the userId. Now technically the userId is redundant in the where clause because the Id will uniquely find one record/document. However adding the userId makes sure the record belongs to the user that's doing the update and not the malicious user.
I'm assuming that there's an encrypted token or session of some sort that the server is decrypting to ascertain the userId and that this is not supplied by the client otherwise that's obviously not safe.
A nice solution would be the following: To quote Sam Newman's "Building Microservices":
The calling system would POST a BatchRequest, perhaps passing in a
location where a file can be placed with all the data. The Customer
service would return a HTTP 202 response code, indicating that the
request was accepted, but has not yet been processed. The calling
system could then poll the resource waiting until it retrieves a 201
Created indicating that the request has been fulfilled
So in your case, you could POST to server but immediately get a response like "I will save the PlaylistItem and I promise its Id will be this one". Client (and user) can then continue while the server (maybe not even the API, but some background processor that got a message from the API) takes its time to process, validate and do other, possibly heavy logic until it saves the entity. As previously stated, API can provide a GET endpoint for the status of that request, and the client can poll it and act accordingly in case of an error.