Identify client to have personal tokens

[susikaman]

Simple working concept for requesting personal tokens based on the user's encoded email address. Encodes self.mail and sends it to the API as an additional param.

[ikagod]

Pretty sure we can drop the base64 encoding and introduce some sha256 hashing.
The point is not to "identify" anyone, as a matter of fact, that should be avoided at all costs. The point is to create a unique token based on the users email that can not be converted back into the original email.

[susikaman]

Pretty sure we can drop the base64 encoding and introduce some sha256 hashing. The point is not to "identify" anyone, as a matter of fact, that should be avoided at all costs. The point is to create a unique token based on the users email that can not be converted back into the original email.

I agree, that's why this is called a concept. This example was made as simple as possible, I didn't wanna go ahead and add any extra dependencies which would be required for a proper encryption.
Users should definitely not be able to be identified, indeed. But in order to have user-specific tokens generated, we need some kind of way to identify individual clients in order to achieve that. As of right now, the only constant we have available is the email address, so the best option would be encrypting that and use the encryption as the user's/client's seed.

[ElieTaillard]

I find it a bit weak to rely solely on the email for seed generation. Perhaps it would be better to include another value, such as the password or some kind of key, to enhance security. Considering that someone's email can be exposed, wouldn't it be easy to recover someone's seed with just their email?

A suggestion could be to use both the email and password for seed generation, as demonstrated in the following code:

import hashlib

def generate_seed(email, password):
    combined_string = email + password
    hashed_seed = hashlib.sha256(combined_string.encode()).hexdigest()
    return hashed_seed

Additionally, if someone manages to obtain another person's seed, they could potentially block their account temporarily, highlighting the importance of incorporating multiple factors for seed generation.

[susikaman]

I find it a bit weak to rely solely on the email for seed generation. Perhaps it would be better to include another value, such as the password or some kind of key, to enhance security. Considering that someone's email can be exposed, wouldn't it be easy to recover someone's seed with just their email?

A suggestion could be to use both the email and password for seed generation, as demonstrated in the following code:

import hashlib

def generate_seed(email, password):
    combined_string = email + password
    hashed_seed = hashlib.sha256(combined_string.encode()).hexdigest()
    return hashed_seed

Additionally, if someone manages to obtain another person's seed, they could potentially block their account temporarily, highlighting the importance of incorporating multiple factors for seed generation.

I was thinking of this first, but then I thought it would be even more insecure to send the user's password to the API along the email. Since email is just an email, it's not even worth trying to decrypt it by force.

The potential for malicious act of abusing the API is surely a possibility. But honestly, do you really think that if someone went ahead and managed to decrypt the user's email, they'd bother messing with their Ikabot access? I highly believe that their skills would offer them some way more valuable things to do than that lol.

[ElieTaillard]

I find it a bit weak to rely solely on the email for seed generation. Perhaps it would be better to include another value, such as the password or some kind of key, to enhance security. Considering that someone's email can be exposed, wouldn't it be easy to recover someone's seed with just their email?
A suggestion could be to use both the email and password for seed generation, as demonstrated in the following code:

import hashlib

def generate_seed(email, password):
    combined_string = email + password
    hashed_seed = hashlib.sha256(combined_string.encode()).hexdigest()
    return hashed_seed

Additionally, if someone manages to obtain another person's seed, they could potentially block their account temporarily, highlighting the importance of incorporating multiple factors for seed generation.

I was thinking of this first, but then I thought it would be even more insecure to send the user's password to the API along the email. Since email is just an email, it's not even worth trying to decrypt it by force.

The potential for malicious act of abusing the API is surely a possibility. But honestly, do you really think that if someone went ahead and managed to decrypt the user's email, they'd bother messing with their Ikabot access? I highly believe that their skills would offer them some way more valuable things to do than that lol.

I was considering generating the seed on the Ikabot side and then sending this hash to the API. This way, we wouldn't be sending the email and password directly to the API, but rather, transmitting a hash. I find it crucial to clarify that my concern initially wasn't about decrypting the email, but rather the potential vulnerability of hashing a known email to obtain the same hash as someone else. This could be exploited to deceive the API by utilizing the hash of another user's email.

[ikagod]

Additionally, if someone manages to obtain another person's seed, they could potentially block their account temporarily,

If someone manages to obtains another person's seed they can only invalidate the token associated with that seed, which is a very minor issue, the user can always log in via cookie (they will probably have to do this anyway at some point considering how strict gf's security regarding the login process is).

potential vulnerability of hashing a known email to obtain the same hash as someone else.

Yes I suppose this could be an issue, as I've explained above but it's a minor one. A third party having a user's email is already a slight security breach, since people nowadays only use their email for logging into online services, instead of sending mail to others. It has basically defacto become a less significant part of the password itself.

I am totally opposed to sending the user's password to any kind of external server and I take a very hard stance on this. We do not need to have long debates with conspiracy theorists about whether or not ikabot steals your account, and what it's transmitting to external servers. It's easier to just not do it at all. I think sending a hash of the email is in and of itself is already a stretch.

I would also like to add that I think if we are going to hash the email we should hash it multiple hundreds if not thousands of times, just to make it harder for someone who potentially has the hash to reverse it into an email.

[susikaman]

Additionally, if someone manages to obtain another person's seed, they could potentially block their account temporarily,

If someone manages to obtains another person's seed they can only invalidate the token associated with that seed, which is a very minor issue, the user can always log in via cookie (they will probably have to do this anyway at some point considering how strict gf's security regarding the login process is).

potential vulnerability of hashing a known email to obtain the same hash as someone else.

Yes I suppose this could be an issue, as I've explained above but it's a minor one. A third party having a user's email is already a slight security breach, since people nowadays only use their email for logging into online services, instead of sending mail to others. It has basically defacto become a less significant part of the password itself.

I am totally opposed to sending the user's password to any kind of external server and I take a very hard stance on this. We do not need to have long debates with conspiracy theorists about whether or not ikabot steals your account, and what it's transmitting to external servers. It's easier to just not do it at all. I think sending a hash of the email is in and of itself is already a stretch.

I would also like to add that I think if we are going to hash the email we should hash it multiple hundreds if not thousands of times, just to make it harder for someone who potentially has the hash to reverse it into an email.

This is exactly what I thought, sending the user's password to the API is the worst possible thing to do imo. Email should be enough, and even that should obviously be properly encrypted, though in such a way that the encryption hash remains constant.

Or, maybe it was possible to have the API create an additional seed for Ikabot to combine with the user's password to increase security/encryption but still being able to identify the client for personal token generation. This would need 2-way communication with the API which would obviously create some new problems, as well as some more traffic for the API.

[ikagod]

I've been thinking about this issue and I've come up with an alternate solution. We could simply extend Ikabot's internal user-agent list (add at least a couple dozen different user-agents) and then make ikabot chose one of those based on the email / pass combo that is provided to it. Then this user-agent will be used internally inside of ikabot, but could also be sent to the API and then the API could generate a blackbox token with the provided user-agent.

This way, there is no need to send any emails or passwords to a third party API, and on top of that the usage of a user-agent stays consistent across both the token and the requests sent by the ikabot instance.

[ElieTaillard]

That sounds good to me

[ElieTaillard]

I close this PR cause a solution has been implemeted in this PR #243