4 ms·

Ask HN: Encrypted File as a Login Method

2 points by anbardoi 2y ago

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: Generate a file containing a random string of text, then encrypt it 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. 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. 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) 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.

hcta 2y ago
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. 2. You should always "salt" stored password hashes. https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) 3. I think you should look at resources like https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-your-own-crypto https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-you... https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul... https://www.infosecinstitute.com/resources/cryptography/the-dangers-of-rolling-your-own-encryption/ https://www.infosecinstitute.com/resources/cryptography/the-... to examine the arguments against trying to develop your own security schemes as someone with less experience in this space.
- anbardoi 2y ago
  I appreciate the resources, I read each of them. The file is essentially no different from a password, but the major difference here is that I would not store the file on my server, nor the decryption keys. Only the sha256 checksum of the file. An attacker can do very little with a checksum associated with user data. I know this is a novel approach, but thats why I'm trying this on a project that is hardly sensitive as an anonymous blogging platform. If there are vulnerabilities, the data gained by an attacker would not even be very valuable.
foldr 2y ago
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.
- anbardoi 2y ago
  Right, that is my intention. I loathe the current software landscape of hand-holding and unhealthy dependency on a company to properly handle a user's data. With this method, the user is responsible for their own security, and I just provide a secure way for them to blog anonymously with virtually no risk of their posts being associated with them. Thats my vision anyway.
1oooqooq 2y ago
it can be much simpler. just use s random number. see how mullvad does it
pestatije 2y ago
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
- anbardoi 2y ago
  The service I'm creating is an anonymous blogging website with a '.dev' extension. It will be made for developers, who are more technically inclined. The reason I am intentionally not considering user device security, is because with this method, I intend to give users ownership of their data. They own their computer, they own their security. I just want to provide a secure means of blogging where they dont have to worry about my server being compromised, because if it is, the attacker will only see sha256 checksums associated with user posts/comments. The posts/comments themselves will be publicly available just by visiting the website.
gus_massa 2y ago
> Generate a file containing a random string of text, then encrypt it. If it's random, why do you need to encript it? > 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. 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?
- anbardoi 2y ago
  But there's no email or username. No identifier. That's what makes it useful from a privacy standpoint. That, and the only way a user can login is if they upload a file that generates the matching checksum in my database. Whereas with hashed passwords, there's more avenues for an attacker to reveal the actual password. If all they have is only a sha256 sum, they'll probably just give up. Idk maybe I'm wrong and this is pointless to pursue. And I'm not sure what bcrypt or scrypt is, I just thought sha256 would be sufficient for the use case.
  - gus_massa 2y ago
    I misssed the no-username part ... So everyone is AnonymousCoward. You will need a lot of moderation. My recomendation is to horseshoe this to a standard user+password implementation, becuase people that know more about security than you and me have thought about it. Perhaps your server can just ignore the username, so everyone is forced to be anonymous. The file you are proposing is a password. It's just a strong password generated by the server intead of a hand made silly password. Usualy there is an implicit user->salt table in the server (that is the first part of the stored hash). So you will have unsalted passwords, that is probably not a problem if they are really strong and are not reused. If you use a standard ignored_username+strong_password then the browser or a password administrator can keep them and makes the user life easier. (I'm not sure about the supporr of server generated passwords in browsers and administrators.) Note: bcrypt or scrypt are hashes designed for passwords. They are relatively slow to prevent brute force atacks. The slownes can be regulated and they include salt. https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Scrypt

2 points by anbardoi 2y ago

hcta 2y ago

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. 2. You should always "salt" stored password hashes. https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) 3. I think you should look at resources like https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-your-own-crypto https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-you... https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own https://security.stackexchange.com/questions/18197/why-shoul... https://www.infosecinstitute.com/resources/cryptography/the-dangers-of-rolling-your-own-encryption/ https://www.infosecinstitute.com/resources/cryptography/the-... to examine the arguments against trying to develop your own security schemes as someone with less experience in this space.

anbardoi 2y ago
I appreciate the resources, I read each of them. The file is essentially no different from a password, but the major difference here is that I would not store the file on my server, nor the decryption keys. Only the sha256 checksum of the file. An attacker can do very little with a checksum associated with user data. I know this is a novel approach, but thats why I'm trying this on a project that is hardly sensitive as an anonymous blogging platform. If there are vulnerabilities, the data gained by an attacker would not even be very valuable.

foldr 2y ago

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.

anbardoi 2y ago
Right, that is my intention. I loathe the current software landscape of hand-holding and unhealthy dependency on a company to properly handle a user's data. With this method, the user is responsible for their own security, and I just provide a secure way for them to blog anonymously with virtually no risk of their posts being associated with them. Thats my vision anyway.

1oooqooq 2y ago

it can be much simpler. just use s random number. see how mullvad does it

pestatije 2y ago

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

anbardoi 2y ago
The service I'm creating is an anonymous blogging website with a '.dev' extension. It will be made for developers, who are more technically inclined. The reason I am intentionally not considering user device security, is because with this method, I intend to give users ownership of their data. They own their computer, they own their security. I just want to provide a secure means of blogging where they dont have to worry about my server being compromised, because if it is, the attacker will only see sha256 checksums associated with user posts/comments. The posts/comments themselves will be publicly available just by visiting the website.

gus_massa 2y ago

> Generate a file containing a random string of text, then encrypt it. If it's random, why do you need to encript it? > 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. 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?

anbardoi 2y ago
But there's no email or username. No identifier. That's what makes it useful from a privacy standpoint. That, and the only way a user can login is if they upload a file that generates the matching checksum in my database. Whereas with hashed passwords, there's more avenues for an attacker to reveal the actual password. If all they have is only a sha256 sum, they'll probably just give up. Idk maybe I'm wrong and this is pointless to pursue. And I'm not sure what bcrypt or scrypt is, I just thought sha256 would be sufficient for the use case.
- gus_massa 2y ago
  I misssed the no-username part ... So everyone is AnonymousCoward. You will need a lot of moderation. My recomendation is to horseshoe this to a standard user+password implementation, becuase people that know more about security than you and me have thought about it. Perhaps your server can just ignore the username, so everyone is forced to be anonymous. The file you are proposing is a password. It's just a strong password generated by the server intead of a hand made silly password. Usualy there is an implicit user->salt table in the server (that is the first part of the stored hash). So you will have unsalted passwords, that is probably not a problem if they are really strong and are not reused. If you use a standard ignored_username+strong_password then the browser or a password administrator can keep them and makes the user life easier. (I'm not sure about the supporr of server generated passwords in browsers and administrators.) Note: bcrypt or scrypt are hashes designed for passwords. They are relatively slow to prevent brute force atacks. The slownes can be regulated and they include salt. https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Scrypt https://en.wikipedia.org/wiki/Scrypt