Let users log into Smoothie

[teolemon]

What

Let users log into Smoothie
https://github.com/openfoodfacts/openfoodfacts-dart/blob/master/DOCUMENTATION.md#check-login-data

Part of

• Add user management #419

[monsieurtanuki]

I suppose we'll have to store the password locally.
How do you guys do that in the 100% Android app? I mean, storing it in clear in the preferences wouldn't be 100% safe. Unless we assume that we can survive if an OFF account gets hacked.
@stephanegigandet @teolemon ?

[M123-dev]

@monsieurtanuki , that's a further reason why I'd recommend Hive (doesn't matter if for all or only for preferences and this). It has some basic encryption at it's core but it also has secured Boxes where you can provide some further encryption. But we'll have to check how it really works

[monsieurtanuki]

@M123-dev We did share views about databases in general and hive more specifically in #470. The issue is on the shelf as it did not draw that much interest, unfortunately. Which is a pity before Smoothie actually goes live, because changing DBs on a live app is quite a challenge!
That being said, we're talking about open source code: the cyphering algorithm can be read by everybody. And I don't know how easy it is for malicious developers to access whatever cyphering keys we will need and store on the device.

[M123-dev]

Yes I know @monsieurtanuki we should probably reactivate the discussion...

On Android, we can decide where to store the data

• public: In the open file system
• private: Only accessible by the app itself and the user
• secured: Even hidden from the user

(They are named differently and this doesn't apply for rooted devices)

The DB is very likely in private and the preferences in secured so I don't worry so much about that. For iOS, it's probably even stricter.

[monsieurtanuki]

You're right, that's probably OK like that so because even on a rooted device the worst that could a user do would be a self-hack! Unless of course the smartphone is given temporarily to a "friend". I had a slightly different issue on another app where I wanted to store the number of purchased credits in the preferences - on a rooted device the user would be able to add credits by directly changing the preferences.

Actually, we don't even have a problem with preferences (deemed "secured"), do we?

[M123-dev]

Now thinking about it that way, it should be allright

[M123-dev]

@monsieurtanuki, now after the switch to hive where would be the correct way to write the logic, should I create a own DaoCredentials or a somewhat more generic DaoString or DaoSecuredString

[monsieurtanuki]

Hi @M123-dev!
It looks like the encryption on hive is at the "box" level, therefore it would indeed make sense to create a dedicated DaoSecuredString class with a dedicated box.
But in a first step I would put it simply in the preferences: as already said preferences are relatively secure, and all the tap dancing you put on encryption will be visible in the code anyway as we're open source.