[
https://issues.apache.org/jira/browse/ROL-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618362#comment-13618362
]
Noah Slater edited comment on ROL-1959 at 3/31/13 4:00 PM:
-----------------------------------------------------------
I'm not quite sure what to make of your response, to be honest. As a member of
the foundation, why would I want to "smear" Roller? I'd also remind you that
assuming the best in people is a core principal of how we are supposed to
operate here.[1]
To address your specific points:
* The purpose of the second validation field in many web forms is to compensate
for the likelihood that when a human types something (especially when it is
hidden) there is a good chance that a mistake will be made. If you are able to
side-step this problem by copying the password from a clipboard, that does not
defeat the purpose of the validation, it obviates it.
* What do you mean when you say that passwords are supposed to be easy to
remember? Who supposes this? Passwords, in security literature, are usually
defined as "something you know". For example, two-factor authentication is a
combination of "something you know" (i.e. a password) and "something you have"
(i.e. an authentication fob, random number generator, or whatever). Being able
to remember a password is convenient for sure, but seems fundamentally
unrelated to its use as an authentication mechanism. (i.e. Makes it no more or
less secure.)
* You point out that during your time at the Department of Defence, you never
heard of anybody using password generators. I would counter by saying that
combination password generators/managers are very popular. Unfortunately, I was
unable to dig up any statistics on this. I did find that Norton (a Fortune 500
company specialising in computer security) have one they make for consumers.[2]
However, I use 1Password, which I believe is the most popular app of this kind
for OS X. Stu Helm, of AgileBits, says[3] that they are "probably into the 100s
of thousands [of users] if not more by now. What I can tell you is that we have
61,786 registered members on our forums."
* Limiting a ZIP code field to 5 characters seems sensible, I agree. But I
would hope that if you were able to submit a form with more than 5 characters
for this field, that the web application would validate that on the server, and
return the user back to the form with an error. From my experience developing
web applications, this could be as little as an additional three lines of code
in a validation class. My argument is not that using HTML to limit the length
of form fields is bad practice. (Though I am not sure where you got the 98%
figure from.) My argument is that silently truncating data and not doing proper
server-side validation is bad practice. I can't back this up with anything
concrete, as the industry as a whole is too immature to have a reference canon.
All I can say is that silently munging data is, in my experience, generally
frowned upon, because it can lead to unexpected situations exactly like the one
I ran into here.
* You actually did solve my problem! I was able to log in again after trying a
20 character substring! So thanks for that.
* I use the maximum length allowed by 1Password when generating my passwords.
As I never have to look at them, or remember them, it makes no difference to
me. And so there is no reason why I shouldn't just go with the most secure
option every time. I tried to download Norton's password generator/manager
tool, but unfortunately I needed a US iTunes account. I wouldn't be surprised
if other popular tools allow passwords of this length. So, I guess my point is:
I see no reason why any tool would limit the length or makeup of a password.
Any such restrictions arbitrarily limit the strength of what passwords can
used. And I don't understand why that would ever be a goal. But let's say that,
in this instance, Roller does want to limit the length of passwords. My
argument is that your password change form should do server-side validation and
warn users instead silently truncating their data. The fact that I managed to
effectively lock myself out of Roller is a demonstration that this is a real
problem. It's only one data point though, so I am not sure of the prevalence.
But if password generators/managers are becoming more popular, this could
become more frequent.
* About the title of the bug, in the description, I put: "Sorry for the vague
ticket title. I don't want to make presumptions about the issue." My meaning
was that I didn't know what the problem was. From my perspective I had a) set a
new password, b) logged out, and then c) lost access to my Roller account. So I
guess a more descriptive title might've been "Setting a password doesn't work"
or something. Where "work" here is defined as leaving Roller in a state where I
can log back in using the new password I just set.
* I attached a screenshot with my last comment. This is what it looks like when
I copy and paste a long password into the field. The space to the right of the
field might suggest it to me. But it is by no means obvious. If I was asked to
stop and consider it, I might conclude that the text as just been scrolled off
to the left, and that the field has some right-padding. But the fact of the
matter is that I did not expect the password to be truncated, and so completely
missed this. If I had realised that the text had been truncated, I would have
used the substring to access my account, and I would not have asked the
infrastructure team on IRC to help me, or subsequently created both an
infrastructure JIRA ticket and a Roller ticket.
[1]
https://svn.apache.org/repos/private/committers/voluntary-code-of-conduct.txt
[2] https://identitysafe.norton.com/
[3] http://www.quora.com/1Password/How-many-users-does-1Password-have
was (Author: nslater):
I'm not quite sure what to make of your response, to be honest. As a member
of the foundation, why would I want to "smear" Roller? I'd also remind you that
assuming the best in people is a core principal of how we are supposed to
operate here.[1]
To address your specific points:
* The purpose of the second validation field in many web forms is to compensate
for the likelihood that when a human types something (especially when it is
hidden) there is a good chance that a mistake will be made. If you are able to
side-step this problem by copying the password from a clipboard, that does not
defeat the purpose of the validation, it obviates it.
* What do you mean when you say that passwords are supposed to be easy to
remember? Who supposes this? Passwords, in security literature, are usually
defined as "something you know". For example, two-factor authentication is a
combination of "something you know" (i.e. a password) and "something you have"
(i.e. an authentication fob, random number generator, or whatever). Being able
to remember a password is convenient for sure, but seems fundamentally
unrelated to its use as an authentication mechanism. (i.e. Makes it no more or
less secure.)
* You point out that during your time at the Department of Defence, you never
heard of anybody using password generators. I would counter by saying that
combination password generators/managers are very popular. Unfortunately, I was
unable to dig up any statistics on this. I did find that Norton (a Fortune 500
company specialising in computer security) have one they make for consumers.[2]
However, I use 1Password, which I believe is the most popular app of this kind
for OS X. Stu Helm, of AgileBits says that they are "probably into the 100s of
thousands [of users] if not more by now. What I can tell you is that we have
61,786 registered members on our forums."
* Limiting a ZIP code field to 5 characters seems sensible, I agree. But I
would hope that if you were able to submit a form with more than 5 characters
for this field, that the web application would validate that on the server, and
return the user back to the form with an error. From my experience developing
web applications, this could be as little as an additional three lines of code
in a validation class. My argument is not that using HTML to limit the length
of form fields is bad practice. (Though I am not sure where you got the 98%
figure from.) My argument is that silently truncating data and not doing proper
server-side validation is bad practice. I can't back this up with anything
concrete, as the industry as a whole is too immature to have a reference canon.
All I can say is that silently munging data is, in my experience, generally
frowned upon, because it can lead to unexpected situations exactly like the one
I ran into here.
* You actually did solve my problem! I was able to log in again after trying a
20 character substring! So thanks for that.
* I use the maximum length allowed by 1Password when generating my passwords.
As I never have to look at them, or remember them, it makes no difference to
me. And so there is no reason why I shouldn't just go with the most secure
option every time. I tried to download Norton's password generator/manager
tool, but unfortunately I needed a US iTunes account. I wouldn't be surprised
if other popular tools allow passwords of this length. So, I guess my point is:
I see no reason why any tool would limit the length or makeup of a password.
Any such restrictions arbitrarily limit the strength of what passwords can
used. And I don't understand why that would ever be a goal. But let's say that,
in this instance, Roller does want to limit the length of passwords. My
argument is that your password change form should do server-side validation and
warn users instead silently truncating their data. The fact that I managed to
effectively lock myself out of Roller is a demonstration that this is a real
problem. It's only one data point though, so I am not sure of the prevalence.
But if password generators/managers are becoming more popular, this could
become more frequent.
* About the title of the bug, in the description, I put: "Sorry for the vague
ticket title. I don't want to make presumptions about the issue." My meaning
was that I didn't know what the problem was. From my perspective I had a) set a
new password, b) logged out, and then c) lost access to my Roller account. So I
guess a more descriptive title might've been "Setting a password doesn't work"
or something. Where "work" here is defined as leaving Roller in a state where I
can log back in using the new password I just set.
* I attached a screenshot with my last comment. This is what it looks like when
I copy and paste a long password into the field. The space to the right of the
field might suggest it to me. But it is by no means obvious. If I was asked to
stop and consider it, I might conclude that the text as just been scrolled off
to the left, and that the field has some right-padding. But the fact of the
matter is that I did not expect the password to be truncated, and so completely
missed this. If I had realised that the text had been truncated, I would have
used the substring to access my account, and I would not have asked the
infrastructure team on IRC to help me, or subsequently created both an
infrastructure JIRA ticket and a Roller ticket.
[1]
https://svn.apache.org/repos/private/committers/voluntary-code-of-conduct.txt
[2] https://identitysafe.norton.com/
[3] http://www.quora.com/1Password/How-many-users-does-1Password-have
> Enhance Roller to support Infinite Length passwords
> ---------------------------------------------------
>
> Key: ROL-1959
> URL: https://issues.apache.org/jira/browse/ROL-1959
> Project: Roller
> Issue Type: Improvement
> Reporter: Noah Slater
> Assignee: Roller Unassigned
> Attachments: roller_password_screenshot.png
>
>
> Sorry for the vague ticket title. I don't want to make presumptions about the
> issue.
> Steps to reproduce:
> 1. Log in
> 2. Set your password to something long and complex like:
> xaQ}W,3tg4.VkAy4b398C9cRu8gE$vm{%f}V;L96bJyWf}#ELa
> 3. Log out
> 4. Try to log back in again
> What I see:
> I am unable to log in.
> What I expect to see:
> I am able to log in.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
