When I designed my programmer’s portfolio site one of the things I noted it needs was my contact information. One alternative to doing that is a contact form, which has the advantage of avoiding spam from being sent to your e-mail address. However, I also found it very unnatural compared to having it open the user’s e-mail client or phone client. The `mailto:` and `tel:` links are the standard practice for contact information links, but it has the flaw of spam bots extracting the information and storing it for robocalls in the future.
So I get around it by obfuscating the links and text so that these bots would have a slightly harder time of getting the data.
Continue reading Obfuscating mailto and tel links
The default installation of DietPi and Dropbear is not too secure as it utilizes
dietpi as the default root password on installation.
Continue reading Securing DietPi with Dropbear
In perusing the Meteor guide section on securing methods with validated-method I didn’t like the way clients had to implemented it and to use it as well. For one it’s not very OO and relies on the fact that you can change behaviour of any part of Ecmascript code. So I wrote up my own implementation that ended in tasks.js in Meteor boilerplate.
Continue reading A Meteor Collection approach
I’ve worked on several projects now and practically every one of enough scale of them had the login use case. In in almost all those cases, I tend to be the one working on it. Even with other tools I have used such as Sonar, Redmine and Jenkins I had to deal with the login because they each had developed their own systems and kept it with the application. It’s only Curam projects that I worked on and one web app of my entire career where I actually used container managed authentication. My preference … container managed authentication hands down.
However, container managed authentication is not really the most trivial thing to do. In the past every application server had its own way of doing things. Thankfully Java EE 6 had brought in JASPIC as part of the standard (even if it is quite out of date in implementation). Now if we mix it with OAuth 2.0, we can push the authentication out of the app and the app server itself and put it in an enterprise OAuth 2.0 server instead of having just a thin veil in the application using Form based login.
I had recently implemented HTTP Header based authentication with JASPIC; this post talks about using the OAuth 2.0 system on JASPIC.
Continue reading OAuth 2.0 JASPIC implementation
When doing something as critical as authentication especially something that would get standardized like OAuth 2.0, security is something that shouldn’t be taken likely. This is true when dealing with messages.
SSL already provides us with relatively reliable transport level security, but what about the data? That’s where cryptographic signatures come in. In SSL we have trusted certificates already loaded into our browsers. However, outside of that it is dependent on the application.
In terms of OAuth 2.0, having a way of trusting the message that gets sent by the remote system needs a way of performing this key interchange. In which case we have the JSON Web Key standard that provides us with a simple exchange of keys. This post talks about how to parse those structures and using them to validate as a follow up of parsing the JSON Web Token in Java.
Continue reading Parsing JSON Web Key (JWK) in Java