Release: SAFE Authenticator Mobile v0.1.1

DGeddes · March 6, 2019, 10:03am

Hi All,

We’ve updated the SAFE Authenticator for mobile.

See the post here for more details:

Ta,
David.

swiesend · March 7, 2019, 2:55pm

Hey,

I’ve downloaded it yesterday and it looks pretty good yet! I liked the intro part.

But I have some concerns.

general:

Account Secret vs. Account Password

What happens if a user switches them by accident?
Is there a way to update both passwords?
Would it be possible to unify both secrets into one? Maybe by a masterpassword which loads both secrets from a secret storage.

mobile:

Interaction:

Wouldn’t it be better to create an authentication flow, if there can’t be used one masterpassword:
Account Secret View -> Account Password View
I think it is pretty important to ephasize that - I think the Account Password right? - never leaves the device. This should be explained visually (remote/local icon) and by a short info.
Maybe it should be possible to input both in the same view, if the user requests so, to be able to use a password manager autocomplete. I don’t know there a any standard for secret autocompletion under Android.

Usage:

Another thing is the apk size. I know you guys went with Xamarian so far, but why is the size so big? IMHO this app should not be bigger than 5MB -> better user adoption for users with low bandwidth (e.g this applies even for rural parts in Germany).

drehb · March 7, 2019, 9:28pm

One gives the network location of the user’s account info, and the other is the encryption key, so mixing them up is not going to work.

ravinderjangra · March 8, 2019, 7:59am

Hey @swiesend,

Thank for the feedback.

As @drehb already commented, the account secret is used to get the location of the user’s account info and account password is used for encryption. So, mixing up both of these is not going to work.

Is there a way to update both passwords?

Currently, we don’t have the option to update account secret/password.

Would it be possible to unify both secrets into one? Maybe by a masterpassword which loads both secrets from secret storage.

Do you mean secret storage on the device?
Yes, we can store the credentials and add a masterpassword / PIN / fingerprint lock.

Wouldn’t it be better to create an authentication flow , if there can’t be used one masterpassword:
Account Secret View -> Account Password View

Do you mean to add this flow for the login page too?

I think it is pretty important to ephasize that - I think the Account Password right? - never leaves the device. This should be explained visually (remote/local icon) and by a short info .

Yes, the account password does not leave the system.
The visual representation sounds like a good idea. We’ll take this into consideration moving forward.

Maybe it should be possible to input both in the same view, if the user requests so, to be able to use a password manager autocomplete. I don’t know there a any standard for secret autocompletion under Android.

On the login screen, both of the fields are on the same view/page so you should be able to use some password manager autocomplete.

Another thing is the apk size . I know you guys went with Xamarian so far, but why is the size so big?

The APK size is bigger because of multiple reasons:

It’s a single APK for different platform architectures (arm-v7a and x86_64) and includes the native libraries for both.
Extra libraries/dependencies required to run Xamarin apps.

There are different approaches to decrease the size of the APK, eg. split APKs for different ABIs, using D8/R8 for compilation and shrinking the bundle, different linker config in android, android app budles etc.

For now, we are releasing the app GitHub so we are not able to take advantage of the dynamic delivery feature provided by Google Play Store.

swiesend · March 8, 2019, 10:44am

@ravinderjangra thank you for your reply.

By that I wanted to know, if the password can get exposed in any way if the user sends one for the other?

Yes, a little animation please. Why Animate?

Seeing forward for the next release. You guys are doing great stuff

digipl · March 9, 2019, 3:41pm

In addition to the fact that the basic communication layer (Crust) are encrypted, the password is secured with a strong Scrypt key derivation function.

github.com

maidsafe-archive/safe_crypto/blob/master/src/lib.rs#L167-L207


      
          
          /// Uses password-based key derivation to securely derive a byte vector from a `password` and
          /// `salt`. `output` may be used to construct any of the keys in this library.
          ///
          /// The optional `work_factor` affects the security of the operation as well as the CPU and memory
          /// required. It must be less than 64. Passing in `None` uses the default of 19.
          ///
          /// `output` must satisfy the following condition: `output.len() > 0 && output.len() <= (2^32 - 1) *
          /// 32`.
          ///
          /// # Example
          ///
          /// ```
          /// use safe_crypto::*;
          ///
          /// let password = b"password!";
          /// let salt = b"salt!";
          /// let mut output = [0; SYMMETRIC_KEY_BYTES];
          ///
          /// derive_key_from_pw(password, salt, None, &mut output).unwrap();

This file has been truncated. show original

ravinderjangra · March 11, 2019, 7:46am

No, it doesn’t. Because to get the location of the data on the network we generate the Hash of the username and use that. So, even if you interchange and enter your password in username field it’s still secure.