so I should prefix this by saying that I dislike talking about projects before they ship because all sorts of things can interfere with timelines and features.
However it’s not a secret that I’ve been working on a massive Secwin update this year (Secwin 7) which I’m hoping will get to release stage sometime over this (our) summer. My goal was to ship before the end of the year, but that looks optimistic, so maybe Jan or Feb next year.
You are right to be concerned. We live in an age when data protection is important, and we need to think about things like this. There are many parts to protecting the data (the MyTable release this coming Friday is part of it) and logins are an important part of the equation.
I’ve already written the new login functionality for Secwin, so I feel comfortable discussing this part.
Logins are complicated because they balance convenience with security. If the security is too inconvenient then people can’t (or won’t) use the program. Too convenient though and the data is not secure. The balance will change from one customer to another. For example some password policies, in common use, have been shown to reduce security not increase it. But some customers insist on these policies, so you have to be able to enforce them “on demand”. I’ve come to realise that this is a customer policy not a developer policy so it’s important for the program to “support everything” and thus let the customer decide which policies they want.
Second (and Third) factor authentication is part of this. I’ve already coded support for SMS and Email second factor authentication, but not yet Google Authenticator. However I’ve designed it to be extensible specifically to allow the adding of something like this (and I suspect it will be added before, or after, Secwin 7 is released.)
But second factor is more than just “implement xxx authentication”. It’s also about when to do it. First time on a new machine? Once a month? Everytime? and so on. Should you allow via Email? via SMS? both? Either? So like with logins there are a lot of possible policies here too.
In addition to this I’ve also added support for Active Directory logins (with or without using the Windows user name), salted-hashed passwords, and a bunch of other login possibilities. It took 5 weeks of solid work, just to do the login screen because there are a lot of parts that had to come together to make it all work easily.
This is just the tip of the Secwin iceberg - there are a lot of other things coming that will appeal to old Secwin, and non-Secwin users. Security has to be done right - it’s something I take very seriously and is obviously very important to both Desktop and Web apps. Hopefully I’ll get to a shipping point before tooo much longer.