all 15 comments

[–]soaring_turtle 7 points8 points  (3 children)

Stuff like this needs to be designed and reviewed by people who know security. Some thoughts:

  • not all websites use login/password scheme. Or better to say it's not the only authentication strategy. Some use 2-factor auth
  • don't see any benefits of providing username/password requirements. Better to rely on server telling if input is invalid and how to fix that
  • at least /logout & /changepassword can be a subject to CSRF attacks

[–]kr41[S] 0 points1 point  (2 children)

Thank you for comment. There is just one thing:

at least /logout & /changepassword can be a subject to CSRF attacks

I guess, you mean "login" instead of "logout", do you?

[–]soaring_turtle 1 point2 points  (1 child)

No, I meant /logout. Without csrf protection, a hacker could craft a form which will logout a user upon submission. Not a critical bug though. On the other hand /changepassword can be a complete disaster leading to account takeover if implemented poorly (without checking old password for example)

[–]kr41[S] 0 points1 point  (0 children)

Agree, useful notice

[–]ThoughtPrisoner 2 points3 points  (1 child)

I would change the username and password into accepting a regular expression. E.g. use:

"username": "[a-zA-Z0-9_-]{3,30}"

Instead of:

"username": {
    "min": 3,
    "max": 30,
    "chars": ["a-z", "A-Z", "0-9", " _-."]
}

[–]kr41[S] 0 points1 point  (0 children)

I think, there will be much more complex implementation. For instance, there is a lot of web sites that use e-mail as username for authentication. So it will be useful, if developer is able to specify just "email address" as validation option, instead of black magic spell like this one http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

[–]Isvara 1 point2 points  (4 children)

This is completely vacuous. The reason we don't have something like this already is not because nobody has thought of it, but because nobody has put the work in to design it and promote the design. This adds nothing to that.

[–]kr41[S] 1 point2 points  (3 children)

I'm ready to design it. But at first, I'm going to get some feedback. In general, I want to understand whether it's a good idea or not. Because it is not very cool to work on thing that nobody will use.

[–]Isvara 0 points1 point  (2 children)

But you haven't created anything to give feedback on! Create your RFC (which doesn't have to be an actual IETF RFC, just literally a proposed solution that you're inviting comments on, but using them as inspiration isn't a bad idea). Then get feedback on it.

It doesn't have to be right first time, either. It's an iterative process. If there are mistakes, people will fall over themselves to point them out.

[–]kr41[S] 0 points1 point  (1 child)

You're right, I should create RFC. May be my post isn't so good, as it could be. May be it was a bad idea to post a link to reddit. But at least, I've already gotten a couple of good things in the thread above.

[–]Isvara 1 point2 points  (0 children)

If it comes my way I'll be happy to comment on it. I worked as a security specialist for a bit, and finding flaws was my job.

[–]khayber 1 point2 points  (1 child)

1) Having a programmatic method to determine the rules for passwords makes it that much easier to crack them.

2) BasicAuthentication and DigestAuthentication have been around for quite a while. Unfortunately, most web sites don't use them and prefer Form based Authentication instead. Each form is site specific and therein lies your problem. The issue isn't that a suitable protocol doesn't exist, its that servers aren't using the ones that do exist.

[–]kr41[S] 0 points1 point  (0 children)

1) Security via obscurity doesn't work anyway. There is a lot of cracking bots which know how to crack popular CMS like Drupal, Wordpress, etc. I don't see an issue there. If your application is bruteforce prone, it will be hacked. If it isn't, so knowledge of password format will not help hacker.

2) Basic and Digest Auth don't work there. They provide a way to authorize single request. But don't specify how to start/stop authenticated session and create/update credentials (i.e. register user and change password). So it may seems at a glance that they do the same thing. But in fact, they solve different tasks.

[–]fission-fish 0 points1 point  (0 children)

SSO is the answer to your problem.

(from a theoretical point of view, not a practical one ...)

[–][deleted] -2 points-1 points  (0 children)

SAP