askfmforhumans / afh-bot Goto Github PK

#⁠1 Password vs. Access token

ASKfm doesn't support OAuth (sigh).
Storing users' passwords is of course insane, but that's what's currently implemented.

We can also use the password to get an access token and store that token. This is preferable (practically this is OAuth). The downside is that it can require manual re-logins when the token gets invalidated.

#⁠2 Plaintext token on the backend vs. Encrypted token in the user's profile

Backend storage is simple, reliable, presumably more secure, but less fun.
The idea of an (almost) completely stateless service appeals to me (I mean no state on the central server, the state is decentralized). That's why I want to store secrets client-side and that obviously requires encryption.

#⁠3 Symmetric vs. Asymmetric encryption

Again, symmetric is just more simple and secure, but less fun.
I think asymmetric is more flexible as it enables more auth flows. Tech-savvy users may generate and encrypt the token themselves or we can offer a client-side utility for it.

#⁠4 Actual cipher

Currently we use RSA with a 1024-bit key, which is not outright insane, but the recommended key size is at least 2048 bits (see this). However, we have very limited space in the user's profile, so anything beyond 128 bytes seems imparctical.

A promising option is eciespy, which requires just 97 + data size bytes and provides integrity guarantees on top of encryption.

Currently we have Password + Encrypted + Asymmetric + 1024-bit RSA.
I want to move to Token + Encrypted + Asymmetric + ECIES.

What we need to store

What storage options we have

More on user config

I prefer decentralized approaches, so I'm after storing user config in users' own profiles.

Credentials are an important subtype of user config. ASKfm doesn't support OAuth (sigh), but we can use the user's password to get an access token and store that token. This is practically OAuth. The downside is that it can require manual re-logins when the token gets invalidated.

Storing credentials on users' profiles obviously requires encryption.
Symmetric is simple and secure, but I think asymmetric is more flexible as it enables more auth flows. Tech-savvy users may generate and encrypt the token themselves or we can offer a client-side utility for it.
A promising option is eciespy, which requires just 97 + data size bytes and provides integrity guarantees on top of encryption.

In the end, storing credentials on users' profiles seems impractical since:

• it requires complex encryption logic
• it takes much space
• credentials don't need to be directly managed by users

Proposed scheme

Roadmap

• move user config to profile description
• provision a DB
• move global config to DB
• move user data to DB
• move UI strings to DB

TBD

I've been running the bot for ~1 week with 3-4 active users before it was blocked by ASKfm without any warning.
Don't know if it's because it asked users for their passwords or for other reasons.

Running in simple mode without a bot has been OK so far.