I am a newbie of the CI framework. I am trying to understand what session id is for. Here is the description from CI doc:
The user's unique Session ID (this is a statistically random string with very strong entropy, hashed with MD5 for portability, and regenerated (by default) every five minutes)
I am just wondering under what occasions I should use this.
Thanks
The session ID in CodeIgniter is essentially either;
if using a database for session storage: a random hash (string) that references the session data in the database so CodeIgniter knows what data belongs to who
if not using a database; an encrypted set of data that CodeIgniter uses (that you can leverage as well) to track the user (eg. if logged in, a user ID)
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.
I'm writing an MVC web application which requires people to login. I want the logged in people to be stored in a database and wondered what the best way of doing this was.
So far I've stored the users session ID and user ID in a table called LoggedOn. Then I can determine if a person is logged on by checking if their sessionID exists in the LoggedOn table.
Is this the best way to do is or is there a better way?
I would store the id and the timestamp of the last action, and delete them if the timestamp is older than a certain amount of minutes, or if they log out.
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.
I am assuming I cannot do this using sessions but rather the DATABASE. So the user would sign in, it would set their TIMESTAMP and I display that from the database. Then it becomes deleted when the user logs out or their session is terminated. How would the code look for this?
The better question is, is my logic correct? Would this work? Does this make sense?
By default application servers store session data in temporary files on the server.
By storing session data in a database table you are able to create an interface that will show information about the users that are logged in. Apart from that, using this (database) approach is a serious advantage if you need to scale your application by adding more than one server.
One of the most popular ways to implement such a functionality is to create a session table containing your users' session data. This may look like:
create table session (
id number primary key,
data varchar(240),
timestamp date
);
The data column stores all the session data in a serialized form this is deserialized each time a user requests the data.
Serialization and deserialization may have inbuilt support depending on the platform you are using. For example, if you are using PHP, the functions session_encode and session_decode may be found useful.
You can't find out when a user logs out in PHP and the Javascript workarounds are a bit far from a stable solution.
A couple of things you need to do: Create a column in your user table called last_activity and update their last_activity to the current time whenever a user loads a page.
For a list of who's online, query the db for users with last_activity values more recent than 10 or 20 or whatever minutes ago.
To update the last_activity column use:
UPDATE users SET last_activity=CURRENT_TIMESTAMP() WHERE id=2
For a list of users online
SELECT * FROM users where last_activity >= (CURRENT_TIMESTAMP()-(60*20))