As a Senior Developer here at Zivtech, part of my job is to develop with an eye towards security. If you follow development and security news, you know that achieving security is pretty hard in complex systems. But, while correctly implementing security across a site is challenging, some aspects of security are actually pretty easy and we've known what to do and what not to do for a long time.

For instance, we know not to use short passwords or use dictionary words as passwords. Solving this wasn't necessarily an implementation problem, it was a user problem. The IT industry has been harping on password strength and training users to come up with stronger passwords over the past few years, and this retraining is working in a good number of scenarios. More and more, we're seeing and using long pseudo-random strings for passwords.

As a consulting company, we are often asked to look at sites or debug server issues for clients who are not always well-versed in web security. At some point in this process there is always a password exchange. It is easy for most people to forget or not understand how careful they need to be when sharing passwords. A password is only good if it is a secret. While we are happy to see savvy clients using strong passwords, it undermines the security of a password if it is exchanged in an insecure way. Unfortunately, the easiest way to send a note (and by extension, a password) is very insecure. I am of course referring to email.

Good solutions are not always easy, easy solutions are almost never good

We know (or should at this point) that emailing passwords is totally insecure and is simply a terrible idea but people do it all the time. Email is sent in plain text across the open Internet. It is susceptible to interception and beyond that it is often left on servers for years as more users have started keeping everything "in the cloud." Zivtech is not the only company to face this challenge with clients. I’ve talked with developers and contractors over and over again about this problem. Many don’t feel that the issue is notable, others recognize the habit as a bad one but don’t see a viable alternative, especially when dealing with less technical clients. In either case, no one ever claims that sending passwords over email is a fine and good idea. It’s just often looked at as a problem with solutions most clients will balk at using or simply won’t use. This has been a source of constant irritation for me over the past few years.

While a system such as LastPass provides excellent security measures it still requires the user to download software and set up an account. This hurdle is enough trouble that many users will simply not do it.

Phone calls are also a good option. But the complexity of a good password and human error often mean that "B7fr2QQdk990" comes out on the other end sounding like "V7sr2QQdk99O". Not to mention that it takes time to coordinate calls and it is simply embarrassing to call back to ask for the password again.

A problem such as this, begs for a technical solution.

A new tool

I wanted a tool that would have a few features specifically to address the problems I have been seeing and struggling against. I had a few key goals and features in mind:

• Secure transmission of data
• Nothing for the client to install
• No account or login needed
• Can be used to receive a password or send one
• Requires no training or discussion for the client

I developed this tool as a Drupal module and named it Secure Notes. I released this as a beta a few weeks ago and we've been using it here at Zivtech.

The module is based on the node system. It's very simple in this respect. When installed, it provides a new content type. A site administrator can customize the fields on the node to meet specific needs but in most cases a plaintext body field is all that is required.

A secure note is nothing more than a node with a bunch of access restrictions imposed on it. Administrators can grant onetime access to create a node by generating a token-based link. This is very similar to the one-time user login link that is sent to users who need to reset their passwords. The link grants the ability for anyone to create a node, once and only once. Once the node is submitted, the token is destroyed.

The reverse is also true. An administrator, or authorized user of the site can create a secure note node, create a one-time view link and send this to anyone. It grants the holder the ability to see a restricted resource once and only once. No login necessary. The link itself can be sent by email and, in fact, this can be automated though a setting in the token generation interface.

Security is controlled though SSL. To truly be effective and secure, the site running secure notes must be accessed over SSL. If that is implemented correctly we can feel as confident about this exchange as we do about sending bank passwords and credit card numbers to online stores. This is well implemented technology that we've been using for years.

Finally, I built a submodule that handles optional cleanup of accessed resources. So if you send a password to a client, it will be marked for deletion after he or she has accessed it. On the Drupal side, received notes can be marked as received and that flags them for deletion as well. That's an important feature because Drupal, by default, isn't a good system to store secure data in the long run. The database and all the text of the site are unencrypted plaintext. Unauthorized access to the site or a database dump would be a significant problem if passwords were sitting around in the site archived for years. The idea is to use the site only for the pickup and drop-off and then clear the data and store it somewhere that is long term secure such as LastPass or an encrypted TrueCrypt file.

Secure Notes is there for you to use now, so please start using it and please stop emailing passwords.

Postscript

Secure Notes should provide enough security for these types of drop-offs and pick-ups but my co-worker, Howard Tyson, proposed a neat concept to make it totally bulletproof. Unfortunately his idea is somewhat at odds with another feature I had been considering so I think I will let the community decide to some extent which feature is more important.

1. Howard had suggested encrypting the stored message just before saving it and then sending the decryption key out as part of the link that allows the user to pick up the note. This would mean that even administrators of the site would not have access to the notes. Even the inviter would not be able to access the note again. Only the invitee could decrypt it. I really like this idea and it seems a useful addition to the tool but if I were to implement it, I would do so by moving away from the node system and just handing the data directly through the database and form systems to ensure I'm not adding unnecessary overhead and to ensure site builders aren't adding fields to the secure note content type that would cause trouble if I tried to encrypt them.
2. My original reason for using the node system was that site builders could build out notes to capture data in a more structured way. For instance they might want username and password fields along with select options etc. I had planned to allow for files (stored as part of Drupal's private file system) to be dropped off and picked up as well. This would mean you could, with much more security than email, send important word documents or pdf documents. This wouldn't really fit in with the totally encrypted model mentioned above.

I'm curious which feature people would be more excited about and would make them more likely to use such a tool. Sound off in the comments below or in the issue queue to help steer future development.

Terms: DevelopmentDrupalmodule developmentSecurityDrupal Planet