Cryptography Encrypted file of plaintext passwords vs plaintext file of individually-encrypted passwords? |
- Encrypted file of plaintext passwords vs plaintext file of individually-encrypted passwords?
- libsodium, but without all the features I don't need?
- Cryptography advice needed
- What is Cryptography?
| Encrypted file of plaintext passwords vs plaintext file of individually-encrypted passwords? Posted: 15 Dec 2018 06:09 PM PST As the title explains, is an encrypted file (let's say AES 128, or something modern) that is storing plaintext passwords any different from a security standpoint than a plaintext file containing lines of individually-encrypted passwords? (Assume any actor who should have privileges to see one password is equally privileged to see all of them). I know there are lots of variables at play here, but just assume the most reasonable ones, if you can. I'm mostly just interested to know the answer in general. But specifically I am encountering this problem with a project that uses LibSodium to encrypt a db of passwords. I'm trying to determine the best approach (of course, you could encrypt the db file AND the contents, but that seems needless). [link] [comments]  |
| libsodium, but without all the features I don't need? Posted: 15 Dec 2018 06:16 AM PST I recently came across lib hydrogen: https://github.com/jedisct1/libhydrogen and I really like the idea of making the smallest possible library. I'm working on a privacy-first chat app, https://emberclear.io which currently uses libsodium.js -- just libsodium compiled to js/WASM libsodium.js itself is ~ 200kb, gzipped -- pretty large (this makes up about 1/3rd of my vendor assets https://nullvoxpopuli.gitlab.io/emberclear/master/bundle.html) my app only really uses the box encryption, and a few utilities, so, I *think* I _ideally_ could maybe get rid of 80% of libsodium. Does anyone know of any projects that are already small? [link] [comments]  |
| Posted: 15 Dec 2018 12:29 PM PST Hey guys, I'm building a website that will need to store user reports as securely as possible. Let's say they're highly confidential, and I'd like the database to stay secure even after a breach.The method I've come up with is currently: - User submits a report. It's encrypted with a public key and stored in the database. - An administrator logs in. The (encrypted with admin's password) private key is fetched from the database and decrypted. User reports are decrypted and now viewable. Now, I've run into a problem. I don't want to ask the administrator for a password each time they want to view a report in detail or go back a page. I've thought of using cookies, but I don't know how to store the user's password in it. I can't really use a session token, as I can't then decrypt the reports. They're encrypted with the user's password. I've thought of using a secure (encrypted) cookie and storing the password in it, but then if an adversary gets ahold of the user's cookie and the machine's cookie encryption key, they could figure out their password. I don't really know if that vulnerability is even avoidable, really. Maybe I should read the cookie encryption key from a file, put it in memory, delete the file and only put it back after the application is shut down? Would that help anything? EDIT: What about decrypting the user's private key, generating a session key, encrypting user's private key with session key, hashing session key and storing it in the server? Do you have any ideas? Thank you for taking the time to read the post. [link] [comments]  |
| Posted: 15 Dec 2018 08:01 AM PST |
| You are subscribed to email updates from Cryptography news and discussions. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment