Here's a gem to use PureScript files with Rails and the asset pipeline. It let's you add and compile PureScript files similar to how CoffeeScript files are added. https://github.com/romaimperator/purescript-rails
* How do you securely log in from an internet cafe?
For this we're going to have to rely on SSL but the server does check that the messages sent by itself and by the browser plugin are not modified in transit and will prevent login if they were.
* What if someone gets your private keys, and gets your password with a keylogger? This looks like "game over."
Well the encryption key is derived using random salts that are in the database so a keylogger alone won't work. Of course it would be trivial to create software to steal the salts as well but if you're computer is infected with malware TrustAuth is no worse than passwords.
To be honest, I didn't think about the similarities between the words. I named it that as an homage to the project's birthplace, a coffee shop named Foam Coffee and Beer.
And yet, people are getting the impression that this has something to do with Rick Santorum's frothy mix of you-know-what. I hope you find a more serious-sounding name soon, before you take whatever the next major step in your project is. What about foamauth? You could argue that it makes the traditional login form disappear into foam, or something like that :)
Thank you for the compliments. With this I was hoping to spark conversation because I've been wondering why something similar hasn't been done yet. We use public key crypto to authenticate with SSH so why not also use it for websites especially with the recent leaks of information like what happened with youporn.
Right now it does not. I can't think of a way to sync across browsers without syncing first to a remote server and I'd prefer not to require people trust my server anymore than they have to. I plan on adding in import/export of the database soon. Here's the roadmap for the addon https://github.com/romaimperator/Foamicator/wiki/Roadmap.
1. One difference is that a different key pair is used for every domain so you don't have to worry about your public key being used to uniquely identify you. Also, I think this is easier for novice users than creating a cert.
2. I plan on adding in an import/export feature for the next release.
3. This should be more secure than passwords because the only information that the server gets is your public key, which of course is assumed to be public knowledge. No more wondering if the website you're using is properly storing passwords.
Do browser-generated SSL client certs really share keypairs between unrelated domains?
AFAIK, each one asks the browser to generate a new keypair. Unless of course they've chosen to be federated with someone who has already issues you a cert.
Yes, browsers can be a bit promiscuous with who they hand your client cert to.
It depends on the browser, who issued the cert, and what websites the user has agreed to supply their client cert for. If a specific website issued the cert, it won't be terribly useful to another site, but it could leak some personal info. If a well-known CA (e.g. DigiNotar) issued the cert, it might be valid across a wide range of sites (e.g. Dutch government and other sites).
The TLS protocol is a bit lacking in this regard. A man-in-the-middle type attacker can impersonate a server to a browser and get the "public" client cert.
