I'm building a web app that sends a person an email every time the person is handed a document (a physical piece of paper). The email contains a link that allows the user to request for a document pick up. The link should contain the user's id and the document's id. Is there a safe way to generate this link? Is this a good practice or are there other ways to implement such a thing?
I was thinking of using a hashing algorithm on the link, is this a good approach?
I'm using expressjs for my server side.
Thanks
Use for example node-uuid to create a UUID and pass it on the link, then store on the database to which document the UUID is linked to.
This solves several problems:
an attacker cannot guess UUIDs
there is no information on the UUID that can be extracted
I don't think hashing would help in this case, as we just need a way to create a one time token that cannot be guessed.
Hashing, obviously, will not include the document and the user's ID. So it's a bit confusing whether you want secure obfuscation (in which case you would want to use a hash algorithm (salt it if you're paranoid) that then quickly checks whether there is a document with the same ID and generates a new one to avoid document-ID mismatch) or that user and document IDs be included (in which case creating a format that includes both and a brief, usually session-dependent, ID to prevent document-ID mismatch will be just perfect).
Related
I need to keep a unique identifier for each client using my react app.
doing this will regenerate a random string (what I want) but does this on each refresh which is not what I want
const [id] = useState(Math.random().toString(36).substr(2, 8));
I've found uniqueId() form lodash but I'm afraid the id's won't be unique across multiple clients as it only give a unique Id and increment it at every call (1, 2, 3...)
const [id] = useState(_uniqueId());
Is there some kind of _uniqueId that generates a random string and also persist through page refresh?
I don't think there is a built-in or out-of-the-box solution that generates unique id in react that persist automatically. You have two problems to solve.
How to generate unique id. Which was already solved by using the uuid.
And how to persist it.
There are plenty of storage you can use depend on your need. Here's few of them where you can persist your data assuming you want it to be stored in client side.
LocalStorage
SessionStorage
Cookie
IndexedDB API
FileSystem
Again, it depends on your use case. So, carefully check them out which one fits on your requirement.
Another way to generate a temporary ID that would be the same for the same client, without storing it is to use browser fingerprinting.
For example, you can take user-agent, client timezone, and screen resolution, apply some hash function to them and call it an ID.
There are more advanced ways of fingerprinting that would result in less chance of two different users having the same ID, but it'll never be a 0% chance.
You also might want to use some libraries, such as https://github.com/fingerprintjs/fingerprintjs for this.
I have a JavaScript application which uses a PouchDB instance to store data. I'd like to replicate that data to a Cloudant instance.
Most of the clients using my app and generating the data are anonymous. I'd like to still collect their data without requiring them to log in or sign up. All of the data they generate is stored in a single document. As you can probably tell, this presents a security challenge.
On the one hand, I'd like to permit anyone to read and write to my CouchDB instance, but I only want to give them access to their data. So, if an anonymous user creates a document, I'd like to only allow them to read/write to that document and not others. I don't want them to simply be able to download my entire database.
Reading the Cloudant and CouchDB documentation, it doesn't seem entirely clear how to achieve this. It looks like the following are possibilities:
Create a new database user each time an anonymous user starts generating data and only give that user access to the document they're going to create.
Create a new database for each anonymous user and somehow replicate that into the centralized database.
Figure out how to securely and transparently authenticate anonymous users.
I'm at a loss, probably due to my inexperience with Couch. How would you implement this?
I'm sure the explanation above will need clarification, so please ask away. Thanks in advance for everyone's help.
I'm interested how does google docs store documents on server side because I need to create similar application.
Does it use pure RTF/ODF files or own database?
How do they make possible versioning and undo/redo feature?
If anybody have knowing according this question please share with me.
To answer you question specifically to how Google Docs works. They use a technology called
Operational Transformation
You may be able to use one of operational transformation engines listed on: https://en.wikipedia.org/wiki/Operational_transform#OT_software
The basic idea is that every operation has a context, e.g. "delete the fourth word in the fifth paragraph" or "add an input box after the button". The clients all send each other operations thru the server. The clients and server each keep their own version of the document and apply operations as they come.
When operations have overlapping contexts, there are a bunch of rules that kick in to resolve conflicts. Like you can't modify something that's been deleted, so the delete must come last in a sequence of concurrent operations on that context.
It's possible that the various clients and server will get out of sync, so you need a secondary algorithm to maintain consistency. One way would be to reload the data from the server whenever a conflict is detected.
--This is an answer I got from a professor when I asked the same thing a couple of years ago.
You should use a database. Perhaps a table storing each document revision. First, find a way to determine whether an update is significant or not. You can store minor changes client side for redo/undo, and then, either periodically or per some condition (e.g., user hits save), create a database entry per revision (you can store things like bytes changed, bytes added, bytes deleted, etc.).
Take a look at MediaWiki, which is open source, and essentially does what you're asking (i.e., take a look at their tables and code).
RTF/ODF would typically be generated, and served, when a user requests exporting the document.
Possibly, you should consider utilizing Google Drive's public API. See link for details.
I'd like to use Firebase to make publicly-readable data whose location is difficult to guess. So, to give someone access to the data stored in "element [element ID = X]", I'd like to just send them "X", instead of sending them "X" along with a security token crafted to give them access to the element. Firebase's push() and childByAutoID seem like a natural fit: I can grant public read access to all individual elements, but deny public listing. My code will be blissfully free of token and random number generation. The automatically generated ID is supposed to be unique, and thus should be difficult to guess.
From looking at Firebase.js, it appears the first 8 characters of the automatically generated ID are based on the current timestamp, and the next 12 characters are randomly generated using Math.random(). I assume that the iOS framework does the same thing, and although I can't see the code, the library links to both SecRandomCopyBytes and arc4random.
For my purposes, this looks good enough, but has anyone seen guidance from Firebase on whether we can count on this behavior? I would hate to build code that assumes these names are relatively strong random strings and then have that assumption violated when I upgraded to a newer version of Firebase.
The purpose of the auto-generated IDs provided by Firebase is to allow the developer to create a chronologically ordered list in a distributed manner. It relies on Math.random and the timestamp to generate an ID unique to that client.
However, if you're going to use the auto IDs as security keys, it may not be the best idea depending on how secure you want your system to be. Math.random is not a cryptographically secure random number generator and since push() relies on it, the IDs generated by it aren't either.
The general concept of giving a user access to some data in Firebase if they know the key is a good one though. We have an example of using this type of security rule, but instead of using push IDs, we use a SHA-256 hash of the content itself (in this particular case, they are images). Hashing the content to generate the keys is more secure than relying on push() IDs.
I have a list of id's stored in my ASP.NET application's session. For contextual purposes:
This is a facebook-like chat module. Id's are relevant to individual chat tabs.
jQuery is handling many things and requires the specific id of each box.
When a new chat session is created, it is given an id on the serverside used for client-side interaction like jQuery event binding
The program works fine I just need a way to access the list on the front-end. I would assume converting the object to a json object makes the most sense but I'm not quite sure where to start.
You can always render server-side content to the client by doing something like:
var ids = '<%= Session["Keys"].ToString() %>';
And then split the results and convert them however you want them. It really depends on what the ID's look like (just numbers, or is more info involved), and how you use them, so it's hard to provide additional advice without more information about the structures.
Add this to your project http://www.nuget.org/packages/Newtonsoft.Json then review this resource http://james.newtonking.com/projects/json/help/index.html?topic=html/SerializingJSON.htm to work out how to do the serialize/deserialize operations ;o)