Electronic Signatures Using The Browser

Sometimes, especially in government or enterprise context, you need to sign a document in the browser using a smartcard (some may call it “crypto token”). It’s rare, but many people have asked me, in private messages and emails, how to do it. Maybe they’ve seen some of my articles from several years ago, but failed to make it work. And my articles show the evolution (or devolution) of in-browser electronic signing. First it was possible with javascript, then I even created a library to make things easier. Then CAPICOM and window.crypto were deprecated, so the only option was to use a Java applet. Then Java applets were deprecated and we were out of options. We got the web crytpo API, but it explicitly didn’t support hardware tokens. For that reason, I wrote a “plea” for smartcard support in browsers, but it hasn’t happened yet and probably won’t in the near future. So what can we do now, that all previous options are deprecated? A good approach is to have a one-time installation of some custom software (it could be a Java Web Start application or a Java-independent application), which runs a local service that listens to a particular port, and then a javascript library that sends the data to be signed to http://localhost:1234/sign and gets the response. There are such solutions available, notably NexU (thanks to efforts put in the DSS package). There are other attempts, such as this one, using Java Web Start (it’s currently not in English). You can try NexU’s demo here. It’s also included in the dss-demo-webapp project. It has some tricky bits that have...

Storing Encrypted Credentials In Git

We all know that we should not commit any passwords or keys to the repo with our code (no matter if public or private). Yet, thousands of production passwords can be found on GitHub (and probably thousands more in internal company repositories). Some have tried to fix that by removing the passwords (once they learned it’s not a good idea to store them publicly), but passwords have remained in the git history. Knowing what not to do is the first and very important step. But how do we store production credentials. Database credentials, system secrets (e.g. for HMACs), access keys for 3rd party services like payment providers or social networks. There doesn’t seem to be an agreed upon solution. I’ve previously argued with the 12-factor app recommendation to use environment variables – if you have a few that might be okay, but when the number of variables grow (as in any real application), it becomes impractical. And you can set environment variables via a bash script, but you’d have to store it somewhere. And in fact, even separate environment variables should be stored somewhere. This somewhere could be a local directory (risky), a shared storage, e.g. FTP or S3 bucket with limited access, or a separate git repository. I think I prefer the git repository as it allows versioning (Note: S3 also does, but is provider-specific). So you can store all your environment-specific properties files with all their credentials and environment-specific configurations in a git repo with limited access (only Ops people). And that’s not bad, as long as it’s not the same repo as the source code. Such...

Audit Trail Overview

As part of my current project (secure audit trail) I decided to make a survey about the use of audit trail “in the wild”. I haven’t written in details about this project of mine (unlike with some other projects). Mostly because it’s commercial and I don’t want to use my blog as a direct promotion channel (though I am doing that at the moment, ironically). But the aim of this post is to shed some light on how audit trail is used. The survey can be found here. The questions are basically: does your current project have audit trail functionality, and if yes, is it protected from tampering. If not – do you think you should have such functionality. The results are interesting (although with only around 50 respondents) So more than half of the systems (on which respondents are working) don’t have audit trail. While audit trail is recommended by information security and related standards, it may not find place in the “busy schedule” of a software project, even though it’s fairly easy to provide a trivial implementation (e.g. I’ve written how to quickly setup one with Hibernate and Spring) A trivial implementation might do in many cases but if the audit log is critical (e.g. access to sensitive data, performing financial operations etc.), then relying on a trivial implementation might not be enough. In other words – if the sysadmin can access the database and delete or modify the audit trail, then it doesn’t serve much purpose. Hence the next question – how is the audit trail protected from tampering: And apparently, from the less than 50%...

User Authentication Best Practices Checklist

User authentication is the functionality that every web application shared. We should have perfected that a long time ago, having implemented it so many times. And yet there are so many mistakes made all the time. Part of the reason for that is that the list of things that can go wrong is long. You can store passwords incorrectly, you can have a vulnerably password reset functionality, you can expose your session to a CSRF attack, your session can be hijacked, etc. So I’ll try to compile a list of best practices regarding user authentication. OWASP top 10 is always something you should read, every year. But that might not be enough. So, let’s start. I’ll try to be concise, but I’ll include as much of the related pitfalls as I can cover – e.g. what could go wrong with the user session after they login: Store passwords with bcrypt/scrypt/PBKDF2. No MD5 or SHA, as they are not good for password storing. Long salt (per user) is mandatory (the aforementioned algorithms have it built in). If you don’t and someone gets hold of your database, they’ll be able to extract the passwords of all your users. And then try these passwords on other websites. Use HTTPS. Period. (Otherwise user credentials can leak through unprotected networks). Force HTTPS if user opens a plain-text version. Mark cookies as secure. Makes cookie theft harder. Use CSRF protection (e.g. CSRF one-time tokens that are verified with each request). Frameworks have such functionality built-in. Disallow framing (X-Frame-Options: DENY). Otherwise your website may be included in another website in a hidden iframe and “abused” through...

Setting Up Cassandra With Priam

I’ve previously explained how to setup Cassandra in AWS. The described setup works, but in some cases it may not be sufficient. E.g. it doesn’t give you an easy way to make and restore backups, and adding new nodes relies on a custom python script that randomly selects a seed. So now I’m going to explain how to setup Priam, a Cassandra helper tool by Netflix. My main reason for setting it up is the backup/restore functionality that it offers. All other ways to do backups are very tedious, and Priam happens to have implemented the important bits – the snapshotting and the incremental backups. Priam is a bit tricky to get running, though. The setup guide is not too detailed and not easy to find (it’s the last, not immediately visible item in the wiki). First, it has one branch per Cassandra version, so you have to checkout the proper branch and build it. I immediately hit an issue there, as their naming doesn’t allow eclipse to import the gradle project. Within 24 hours I reported 3 issues, which isn’t ideal. Priam doesn’t support dynamic SimpleDB names, and doesn’t let you override bundled properties via the command line. I hope there aren’t bigger issues. The ones that I encountered, I fixed and made a pull request. What does the setup look like? Append a javaagent to the JVM options Run the Priam web It automatically replaces most of cassandra.yaml, including the seed provider (i.e. how does the node find other nodes in the cluster) Run Cassandra It fetches seed information (which is stored in AWS SimpleDB) and connects...

Using JWT For Sessions

The topic has been discussed many times, on hacker news, reddit, blogs. And the consensus is – DON’T USE JWT. And I largely agree with the criticism of typical arguments for the JWT, the typical “but I can make it work…” explanations and the flaws of the JWT standard.. I won’t repeat everything here, so please go and read those articles. You can really shoot yourself in the foot with JWT, it’s complex to get to know it well and it has little benefits for most of the usecases. That said, I’ve gone against what the articles above recommend, and use JWT, navigating through their arguments and claiming I’m in a sweet spot. I can very well be wrong. I store the user ID in a JWT token stored as a cookie. Not local storage, as that’s problematic. Not the whole state, as I don’t need that may lead to problems (pointed out in the linked articles). What I want to avoid in my setup is sharing sessions across nodes. And this is a very compelling reason to not use the session mechanism of your web server/framework. No, you don’t need to have millions of users in order to need your application to run on more than one node. In fact, it should almost always run on (at least) two nodes, because nodes die and you don’t want downtime. Sticky sessions at the load balancer are a solution to that problem but you are just outsourcing the centralized session storage to the load balancer (and some load balancers might not support it). Shared session cache (e.g. memcached, elasticache, hazelcast)...