Hide Secrets With ******


atomicorange

Recommended Posts

  • 4 weeks later...

I agree with ChrisH on this

 

Why

 

do you think someone is going to memorize a secret key over your shoulder in the 1 second you paste it into the window?

 

 

the only argument for ******************* ing the password is because you have someone over your shoulder (which can easily be solved)

or you have a malicious program doing screen shots or taking snapshots of your clipboard which if that is the case your system is compromised anyway so the point is still mute 

Link to post
Share on other sites
  • 1 month later...

What would be nice is if you setup the folder via the API to supply a password so that the secret read write is not displayed when requested unless the password is supplied, only avalible through the API

 

 

 

Use Case: Accounting Department shares files between computers. One user is getting fired today and wants to take it all with him.... OMG they have the keys to the castle. 

Link to post
Share on other sites
  • 2 weeks later...

So the user just plugs in his trusty portable harddisk / USB key / smartphone and copies all the juicy data onto that.

 

(Also, WTF? An accounting department that can't afford a simple file server?)

 

You haven't worked for a company called upside... a server is an old developers workstation. :)

Link to post
Share on other sites

Imagine, there is a client that hides keys: the IOS one (and, apparently, the Android one, too, although it can be set up to give out keys). Instead, it offers you "links", so that two peers could share the real key between them. Some folks do feel very uncomfortable with that (see more http://forum.bittorrent.com/topic/31588-wont-use-getsynccom-link-for-sharing/). And that makes sense.

 

However, the IOS client does one good thing. It asks your approval on every new peer it registers to use one of its keys. And that provides for some "server/clients" policy administration. You may write down the key, which would be of no use until approved with every particular peer client.

 

I'd suggest extending this peer approval approach (as an option) to all desktop versions as well (in fact, it already is there, in 1.4), and complementing it with a list of approvals being in effect (currently, you seem not to be able to see whom have you given an approval, or whom have you turned down), and an option to revoke particular approvals per peer client.

 

Certainly, some provisions should be made to describe these approvals in manual config files (like those on Linux, NASes, etc.). And that, in turn, may need some disclosure of peer identifiers that Sync uses. And the latter might help suggesting peers without knowing their IP addresses and incoming ports (I can't tell my desktop client anything about a mobile client, as I can't tell or set up a fixed incoming port on any mobile client, which would also be quite apposite in this context; no matter if I can set up a fixed IP address for it).

 

That would add much more to the feeling of security than just hiding keys from direct view. Although, a sort of passcode to sensitive settings would also be welcome.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.