HN Explorer

Ask HN: Encrypted File as a Login Method

2 points by anbardoi ↗ HN
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.

13 comments

[ 2.8 ms ] story [ 43.5 ms ] thread
hcta
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)

3. I think you should look at resources like https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-you... https://security.stackexchange.com/questions/18197/why-shoul... 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
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
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
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
it can be much simpler. just use s random number.

see how mullvad does it

pestatije
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
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
> 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
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
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/Scrypt

anbardoi
Being an anonymous coward in some countries is better than the alternative. I'm still going to try to do the encrypted file login lol this isn't for personal financial gain or even for some social clout I can gloat about. This is for me to say I did something cool or beneficial for the world. If I could get this to work and gain traction, it will raise the bar for user privacy and maybe put an end to the obvious human data mining operation invading the entirety of the web. In thinking of maybe even doing a SSO service using the same security method.
gus_massa
> Being an anonymous coward in some countries is better than the alternative.

I agree. Good luck with your project. Remember to post it here when it's working or when you have an interesting blog post about an update in the advance of the implementation.

Anyway, as my father used to say, write everithing as if it will be published tomorrow in the front page of a major newspaper of your country.

anbardoi
Thank you for the change of perspective and encouragement. I'm wanting the 1.0 announcement to be an admin blog post from the platform itself.. That way after people read about it, well, they're already there and can try it out or explore the site if they want to.

One of my big concerns is moderation and legal, as I know cybercriminals/scammers will see my platform as a viable tool for their operations. I'm thinking blocking known malicious IP's, maybe some kind of regex system. Ill still new to this so if you have an suggestions, I am desperate to hear them.