Over the past series of posts, Jeetu and myself have been discussing in depth few of the architecture related options with the SSH implementation we are putting into place.
We have seen
Existing keys vs Separate Keys for eBrainPool
Key authentication, host keys and security implications
Another topic raised was the issue of distributing the actual keys itself, when two clients (users) wish to connect . Since all this info. will be exchanged prior to being connected (authenticated) there is a catch-22 situation here.
How do we exchange the keys over an insecure connection. In the real-world we live in, this is usually ( and I think almost exclusively ? ) a manual process. An admin or a user with sufficient privileges copies the key across in what is hopefully a secure manner. In this case, we are asking the keys to be transferred so that a connection can take place. Without the exchange of keys, there can be no password-less session.
Perhaps, to borrow an idea from the bluetooth device connection concepts in use, we make the first connection via password, Lets call it an authentication token. Once the initial connection is made, the required keys are copied and then its all magical from there. Yes perhaps the added user interaction required would be initially painful, but the added interaction introduces a higher layer of security ?
Similar concepts are already used in the real world, that sms-token you get from your bank when attempting a transaction (most banks have implemented stuff like this).
Drawbacks of this:
- Additional User Interaction. Would it detract and make the process of letting someone connect be so painful, that it makes the entire concept of using this redundant ?We want the experience of using eBrainPool to be seamless. Does this break this ?
- Do all people use the same passwords? Ok, yeah maybe not, but needs to be asked you know :)
- How are the authentication tokens (passwords ?) going to be exchanged?
More importantly if they are exchanging passwords this way then why have keys?
How ever it is implemented, what we need perhaps is a way to introduce a parallel authentication mechanism to allow greater security for the users choosing to connect. This ensures that the tried and tested model for ssh security is not inadvertently broken by the very first step in the process.
Got ideas? know better? let us know