If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/)
Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL:
With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves.
> If this is just a communication of risks, then those are not being communicated
Correct, that message is not very informative. I think it will be removed.
Literally just "1". Tells me nothing about what's happening in this change, and from the diff, it looks like quite a lot ("118 changed files with 283 additions and 179 deletions").
Talk about as substance-less criticism as any. A lot of the criticism of his/er project here seems to be on non-substantive things (commit messages, tone of the medium article) and not on the substance (the actual fucking protocol). Classic HN poo-poo'ing on anything that either competes with their service or they've missed the boat on.
Besides, everyone writes shitty messages every now and then. Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
> Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
Except notes rarely are intended to be public and used for communication with other developers. While I agree that bad commit messages every now and then are not a big deal - that is not what the original commenter was referring to. Of the 23 commit messages, 8 of them are just "1".
The only meaningful commit message was from a 3rd party PR that was merged. For security-related code, "hygienic" coding practices, including quality commit messages, are - at least in my eyes - important.
It doesn't. `git commit` will open your $EDITOR to let you modify the full commit message. I would recommend looking at how Linux kernel commit messages are structured.
Except that the commit history is actually important when auditing a security-sensitive project.
After reading the guidelines for the Linux kernel I've always given full and proper commit descriptions for effectively all of my commits (with exceptions for projects which don't matter, and such messages aren't going to be read by anyone -- including me). I really wish more people did this, because it makes bisecting, backporting and otherwise spelunking projects much easier.
To put it in your analogy, it wouldn't be fair to judge a programmer by their handwriting. But it might be fair to judge a secretary by their handwriting (you'd be annoyed if your secretary didn't write down important details, or wrote them in a way that nobody could read them).
It's not really true to say that the commit history of a project is an important aspect in regards to security. Whether it's security-sensitive or not, a project has either been audited or it hasn't. And an audit doesn't rely on commit messages.
Yes, but usually audits are of a single snapshot in the repo's history. Understanding why a change was made is quite important, especially if someone touched security-sensitive code.
This is a worthy goal as I'm sold on passwordless mechanisms too.
Not a telecom provider leaking your SMS codes,
not email provider resetting your passwords, not
Facebook Connect/Google OAuth issuing your access_token
to someone else.
We also need to consider someone who just has access to your phone unlocked .. even if it be your "harmless" kid :) It looks like in the current design, there is no additional safeguard for this - like using a device's finger print scanner.
That's an interesting recommendation that sounds valid. I'm unsure of the user experience - in particular whether a user is likely to be confused by being thrown back to the system unlock. Any notes on non-techies dealing with this in your experience?
You are right, but this is easy to solve. The less nice solution is to show a little explanation before locking the device, the better one depends on OSes. They should simply provide a way for devs to trigger the lock screen for this specific purpouse and let devs specify a message, color scheme, theme, logo, whatever that needs to feel the lock mechanism more integrated in the app.
So if you are a developer, your best bet is "How it works?" here: https://github.com/sakurity/securelogin
If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/)
Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL:
With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves.
> If this is just a communication of risks, then those are not being communicated
Correct, that message is not very informative. I think it will be removed.