suggestions for login screen

[Ravi Tejasvi]

Hello

I wanted to start working on the login screen for Tahrir. 

These are my thoughts:

1st time user has to create an identity, so tahrir will ask for his preferred nick and provide him with the identity. 
Other users can either choose from their existing identities (which they have created) or create a new one. 

Do we have to confirm their identities? Like, by a confirmation mail when they register? And give them an option to recover their password? Do we even need to store their email id in the first place?  

All suggestions are welcome.

Regards
Ravi Tejasvi

[Ian Clarke]

On Sun, Oct 27, 2013 at 9:03 AM, Ravi Tejasvi <ravit...@gmail.com> wrote:

1st time user has to create an identity, so tahrir will ask for his preferred nick and provide him with the identity. 

Other users can either choose from their existing identities (which they have created) or create a new one. 

Yes, that makes sense.

 

Do we have to confirm their identities? Like, by a confirmation mail when they register? And give them an option to recover their password? Do we even need to store their email id in the first place? 

No, I don't think we can do anything with email - that would require that they configure a mail server which would complicate setup, and also it would potentially breach someone's anonymity as their email might be monitored.

Instead, we can tell them the file that contains their identities (their "keychain"), and they can back it up if they want to - but we can do this in the documentation.

I think we could optionally allow them to encrypt their keychain with a password, but that can be a feature for later.  When we do this I don't think there can be any way to recover a password - since their unencrypted password shouldn't be stored anywhere (this would be a security risk).

Ian.

--
Ian Clarke

Blog: http://blog.locut.us/

[Ravi Tejasvi]

I haven't created an app on such a large scale before, so how do we resolve the identity conflicts here? Do we use some part of their public key in the nick as was being implemented by Kieran before? But even that can't be guaranteed to be unique always. So how do we check for the uniqueness? 

Regards
Ravi Tejasvi

--
You received this message because you are subscribed to the Google Groups "Tahrir Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tahrir-developm...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ian Clarke]

On Sun, Oct 27, 2013 at 9:12 AM, Ravi Tejasvi <ravit...@gmail.com> wrote:

I haven't created an app on such a large scale before, so how do we resolve the identity conflicts here? Do we use some part of their public key in the nick as was being implemented by Kieran before? But even that can't be guaranteed to be unique always. So how do we check for the uniqueness? 

I think in the event that two UserIdentities have the same nickName then, when we display it, we should show part of the public key to disambiguate them.  We can call this a "signature" for the public key.

The simple way here would be to convert the public key to base 64 representation, and just show the first 5 characters.  This gives only a 1 in a billion chance that two public keys would have the same 5 characters.  I think this might be adequate for the alpha.

However, this could be exploited maliciously, since it would be possible for an attacker to find another public key that produces the same 5 character signature.

The solution is to use a salt.  When the node starts up for the first time it randomly creates a large number, this is stored so that it can be used in the future.

Now, to create a public key's signature, we combine the public key with the salt, and hash it using a secure hash function.  We then convert this hash into Base 64 and take the first 5 characters.

The advantage here is that, since every Tahrir node will now have a different salt, the signatures for specific public keys will always be different, and the attacker can no longer choose a public key to give a particular signature, because they cannot predict what the signature will be.

Does that make sense?

Ian.

 

[Ravi Tejasvi]

Yes. I'll start working on it. 

Regards
Ravi Tejasvi

--