benguild

"two-Factor" Secrets

Recommended Posts

If the secret length can't be changed, I think that having a "password" (of a variable length) for the secret would be great. Essentially all peers have to verify this password with each other directly for a given secret in order to actually communicate over a given secret.

 

I realize that finding a way to verify passwords peer-to-peer that can't be easily spoofed/monitored/cracked might be a challenge given that there's no central authority, but a feature like this would definitely ease the wary minds of those concerned about the extreme chances of probability.

 

This way, it's ideal since even if someone finds your secret they're most likely not going to find a matching passcode.

 

... Even BETTER would be a way to store, generate securely (based on the original passcode) a secure password "key" that is unique for a particular node... so that the original passcode is never actually stored or given to that node in plain text.

Share this post


Link to post
Share on other sites

If the secret length can't be changed...

The secret length CAN be changed! See this thread.

 

Also, there are already a wealth of other topics dealing with the exact same issue regarding security of secrets - some examples: (1 | 2 | 3 | 4 | 5 | 6 | 7)

Share this post


Link to post
Share on other sites

The secret length CAN be changed! See this thread.

 

Also, there are already a wealth of other topics dealing with the exact same issue regarding security of secrets - some examples: (1 | 2 | 3 | 4 | 5 | 6 | 7)

 

Understood, but not for the new types of nodes. As I understand, the older key styles are only supported for legacy reasons.

Share this post


Link to post
Share on other sites

I like the idea of having a "two-factor" authentication system. Aside from having matching secrets, it'd be nice if the nodes could have a pre-shared key that also has to match or they won't talk to each other.

 

The idea here is that outdated notes could be excluded from the secret without having to change the secret, and it also provides and additional level of security where the user can create an much longer secret key of mixed character sets.

 

 

I think this would be a great advanced/hidden option for added security given that it would be basically impossible for someone to guess a secondary key, but it makes use of the existing 33 character secret system.

 

 

Share this post


Link to post
Share on other sites

What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits.

 

And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it?

Share this post


Link to post
Share on other sites

What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits.

 

And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it?

 

Totally agree!

 

I think it's basically about the perception (or rather misconception!) that people "feel" more secure if they are asked to provide two pieces of information instead of one!

Share this post


Link to post
Share on other sites

Totally agree!

 

I think it's basically about the perception (or rather misconception!) that people "feel" more secure if they are asked to provide two pieces of information instead of one!

 

Right—

However if the second key is of a variable length vs. the first being of a fixed length for simplicity and branding's sake... then that's different.

 

Another way to treat this might be to treat the secondary key as a data encryption key ... where perhaps without it someone can connect to your "stream" just by having your secret, but won't be able to actually decode anything otherwise.

Share this post


Link to post
Share on other sites

I like this idea as well, I have been using Sync for a while and love the simpliciy of it... just wish I had more control over who I send the keys to as I have noticed some friends reply and CC other people into the email with the sync key.

 

I installed syncthings this weekend to have a look at the diffrence.  syncthings has the idea of nodes and repositories... so you set up trusted nodes with two keys.... meaning you set up one node and send your friend a key, he/she has to set up the node on there side with your public key and then send you a public key of their own... so its a two way trusted node.... then when you want to sync a repository with them you simply check a box to "sync" with their node.

 

I for one like BTSync more as it just is a slicker and nicer interface and easier to set up... but I would love to see a better implementation of the key trust.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.