I'm developing an anonymous blogging website that exemplifies user privacy and instead of going the ol' tried-and-true route of requiring an email/password for account creation/login, I want to do this:<p>Generate a file containing a random string of text, then encrypt it<p>Calculate the sha256 checksum of the encrypted file and store it in a database. Then provide the file and the decryption key to the user for download.<p>When the user wants to login, they upload that file to my server in a buffer, where the sha256 is calculated and checked against the database. If it matches, user gains access to their account data, associated with the checksum. If it doesnt, the file is rejected. Either way, the encrypted file is deleted after checking.<p>I think this would be really secure because if my server is compromised, the only thing an attacker would have is sha256 checksums as user identifiers. I know there's probably hashing/file-handling attack vectors, as well as file-collision scenarios(although rare, still possible)<p>Are there any additional considerations I should take into account with this project? Also, security QA's as recovery in case they lose their file.
1. what you're describing as a "file" is really no different from a "password". I assume you're choosing to call it a "file" because you're picturing generating some huge blob, but a randomly generated password doesn't need to be very long to be effectively uncrackable, so I think you're proposing wasting time/bandwidth for no added security.<p>2. You should always "salt" stored password hashes. <a href="https://en.wikipedia.org/wiki/Salt_(cryptography)" rel="nofollow">https://en.wikipedia.org/wiki/Salt_(cryptography)</a><p>3. I think you should look at resources like <a href="https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-your-own-crypto" rel="nofollow">https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-you...</a> <a href="https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own" rel="nofollow">https://security.stackexchange.com/questions/18197/why-shoul...</a> <a href="https://www.infosecinstitute.com/resources/cryptography/the-dangers-of-rolling-your-own-encryption/" rel="nofollow">https://www.infosecinstitute.com/resources/cryptography/the-...</a> to examine the arguments against trying to develop your own security schemes as someone with less experience in this space.
> <i>Generate a file containing a random string of text, then encrypt it.</i><p>If it's random, why do you need to encript it?<p>> <i>When the user wants to login, they upload that file to my server in a buffer, where the sha256 is calculated and checked against the database. [...] Either way, the encrypted file is deleted after checking.</i><p>This is exactly like the standard method to login users. You don't store the password in the server, you only stored a hash of the password. Why are you proposing to use sha256 instead of bcrypt or scrypt?
Storing the password in a file isn't too bad in principle, but it opens the door to user error. It's easy to accidentally upload a file containing a password to the wrong place.
your not considering users device being compromised, nor usability...plus nowadays, to "exemplify user privacy" is not to reinvent the infrastructure but to demonstrate users data is not sold on their back and non-collusion with secret agencies / law enforcement