Implement registration locks about libsignal-service-rs HOT 4 OPEN

I am struggling with this issue too and I'd like to implement this feature too 😅

Some questions

First, I wonder how we can get the information that this account we're trying to register already have a pin. Maybe it is in the answer from /v1/accounts/{}/code/{} ?

Then, once we get this information, there are three possibilities :

1. account has a PIN but is not locked → the user knows the code and then we can send it back (how ?) ;
2. account has a PIN but is not locked → the user doesn't know the code and then can't recover his profile, but he can still register (how to tell Signal this is what the user choose ?)
3. account has a PIN and registration is locked → if the user doesn't know the code, then he's lock for a week and needs to wait.

Does someone know when and how to get the information "this account is PIN protected" ?

Then, when and how to send back the information ?

API paths found in the signal APK

I disassembled the last signal version APK and I found some interesting paths in strings :

• removeRegistrationLockV1(...) does DELETE /v1/accounts/pin
• disableRegistrationLockV2(...) does DELETE /v1/accounts/registration_lock
• setRegistrationLockV1(...) does PUT /v1/accounts/registration_lock with some data (json)

But I think these paths are used after the user is registered so I still need to work to find answers to the questions above.

How libsignal-service is supposed to be used?

My guess is that we may have to use the libsignal-service::account_manager::set_account_attributes(...) function before sending the registration code.

This function applies on an AccountManager struct. In presage, the way to get this account manager is by calling retreive_profile (which calls retrieve_profile_by_uuid with our uid). This only works if we are already registered.

I think the push_service::set_account_attributes(...) from libsignal-service might be useful however I don't know how to use it. First, what is the difference between the pin (in AccountAttribute it is an Option<String>) and the registration_lock (which is also an Option<String>) ?

Anyway if someone has tips, please tell me ! 😃

from libsignal-service-rs.

Useful source of information, including on how to detect a registration lock: https://gitlab.com/whisperfish/whisperfish/-/issues/148

I am not sure about the endpoints, but we tend to spit out the Android source code in order to discover what's going on and what should be done.

As far as I know, the set_account_attributes family of methods can only be used with a valid registration.

I am not sure about the difference between pin and registration_lock, other than that these seem to be two different "versions" of registration locking. We probably want to implement both.

from libsignal-service-rs.

Indeed, there is a string (in res/values/strings.xml) that says "Your Registration Lock is now called a PIN, and it does more. Update it now."

I guess registration lock was only a code stored on Signal servers, preventing a stranger from registering a number (one week delay).

Now, they replaced it whith PIN which is the same thing plus it stores data (account contacts and informations) in a "secure place" which (they say) can only be accessed with this PIN.

It is weird because there is an API for removing the PIN (DELETE /v1/accounts/pin) but no API for updating it. However, there is an API for updating or removing registration_lock (PUT/DELETE /v1/accounts/registration_lock) - which is supposed to be the old way...

I found some things in something called RegistrationCodeRequest ... doInBackground( ). This is where the registration process is handled but I think the HTTP 417 code is not handled... Maybe I didn't understand everything but if i'm right, it means presence of the NIP is handled before sending back the one time code...

from libsignal-service-rs.

It is weird because there is an API for removing the PIN (DELETE /v1/accounts/pin) but no API for updating it. However, there is an API for updating or removing registration_lock (PUT/DELETE /v1/accounts/registration_lock) - which is supposed to be the old way...

I suggest that you already file a patch here which exposes those APIs. That's already an important part of the implementation, and we can merge that independently already.

Then, I think the PIN might be a zero-knowledge password protocol, or something like that. It always helps to find the blog post related to the introduction of those features: https://signal.org/blog/signal-pins/

it means presence of the NIP is handled before sending back the one time code...

Yes indeed, you only get the one-time code if the lock is disabled (or maybe there's an API to request it with knowledge the PIN).

from libsignal-service-rs.