roller-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noah Slater (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ROL-1959) Enhance Roller to support Infinite Length passwords
Date Sun, 31 Mar 2013 15:53:15 GMT

    [ https://issues.apache.org/jira/browse/ROL-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618362#comment-13618362
] 

Noah Slater commented on ROL-1959:
----------------------------------

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

Mime
View raw message