php-general Digest 28 Dec 2010 18:25:07 -0000 Issue 7104
Topics (messages 310261 through 310271):
Do you trim() usernames and passwords?
310261 by: Dotan Cohen
310262 by: Ashley Sheridan
310263 by: Al
310264 by: Dotan Cohen
310265 by: Dotan Cohen
310266 by: Paul M Foster
310267 by: Nicholas Kell
310268 by: Dotan Cohen
310269 by: Govinda
Static content at runtime
310270 by: knl.bitflop.com
310271 by: Govinda
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
I seem to have an issue with users who copy-paste their usernames and
passwords coping and pasting leading and trailing space characters.
The obvious fix was to trim() the values that I receive, but I worry
how that would affect users who use a space at the beginning or end of
their password. Of course, if I trim() also when the user is setting
his password then he will never know that his password is really 1
digit shorter, but do I really want to do that? Thoughts? Thanks!
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Tue, 2010-12-28 at 14:49 +0200, Dotan Cohen wrote:
> I seem to have an issue with users who copy-paste their usernames and
> passwords coping and pasting leading and trailing space characters.
> The obvious fix was to trim() the values that I receive, but I worry
> how that would affect users who use a space at the beginning or end of
> their password. Of course, if I trim() also when the user is setting
> his password then he will never know that his password is really 1
> digit shorter, but do I really want to do that? Thoughts? Thanks!
>
> --
> Dotan Cohen
>
> http://gibberish.co.il
> http://what-is-what.com
>
The copy-paste thing I've noticed only really seems to happen on
Windows, particularly with Outlook. The thing I always tell people if
I'm emailing people a password is that they should type it out rather
than copy paste to avoid these issues. The whitespace usually seems to
consist of newlines and carriage returns, so you could try stripping
those two characters out specifically rather than a full trim().
As you've said, a user might want a space in their password, and should
be allowed to use them. Maybe add a footnote to the password field
reminding people about accidental copied characters, and perhaps a
Javascript counter that displays the number of characters used in the
password field (as a lot of people know their password length but find
counting the password character in a field difficult because the
characters are all the same and the eyes can't follow easily)
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On 12/28/2010 7:49 AM, Dotan Cohen wrote:
I seem to have an issue with users who copy-paste their usernames and
passwords coping and pasting leading and trailing space characters.
The obvious fix was to trim() the values that I receive, but I worry
how that would affect users who use a space at the beginning or end of
their password. Of course, if I trim() also when the user is setting
his password then he will never know that his password is really 1
digit shorter, but do I really want to do that? Thoughts? Thanks!
Can't you simply specify the allowed characters that can be used for PWs and
usernames?
I always do, e.g., 6-8, case sensitive, alphanumerics, and the following
characters: "@, #, $, %, &, *, -".
Then, I trim() and check the submitted PW for any exceptions to the rules.
--- End Message ---
--- Begin Message ---
On Tue, Dec 28, 2010 at 15:12, Ashley Sheridan <[email protected]>
wrote:
> The copy-paste thing I've noticed only really seems to happen on Windows,
> particularly with Outlook. The thing I always tell people if
> I'm emailing people a password is that they should type it out rather than
> copy paste to avoid these issues. The whitespace usually
> seems to consist of newlines and carriage returns, so you could try stripping
> those two characters out specifically rather than a full
> trim().
>
I do trim newlines, carriage returns, null characters, vertical and
regular tabs. However, the space is the problem. I don't think that
telling them to type it out is a good solution as it is "fixing the
user" which, although might be where the problem lies, is never the
solution.
> As you've said, a user might want a space in their password, and should be
> allowed to use them. Maybe add a footnote to the
> password field reminding people about accidental copied characters, and
> perhaps a Javascript counter that displays the number of
> characters used in the password field (as a lot of people know their password
> length but find counting the password character in a
> field difficult because the characters are all the same and the eyes can't
> follow easily)
>
I will add such a footnote in the event of a failed password attempt
(right there with the capslock warning) but I do not think that a
counter is a good method.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Tue, Dec 28, 2010 at 15:27, Al <[email protected]> wrote:
> Can't you simply specify the allowed characters that can be used for PWs and
> usernames?
>
No, I hate when websites do that. It leads to less secure passwords,
not more secure, and it is passing the burden of fixing the issue onto
the user.
> I always do, e.g., 6-8, case sensitive, alphanumerics, and the following
> characters: "@, #, $, %, &, *, -".
>
> Then, I trim() and check the submitted PW for any exceptions to the rules.
>
I regularly use other characters in my passwords. Of the top of my
head, I have passwords with the tilda, underscore, and exclamation
point. Sites that don't let me use them don't get my business.
Seriously. I once even switched banks twice in one week: once because
the old bank's website did not work with Firefox in Fedora, and the
second time because the new bank's website would not let me use an
exclamation point in my password. I might be an extreme example, but
it is behaviour that I do not agree with.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
On Tue, Dec 28, 2010 at 02:49:59PM +0200, Dotan Cohen wrote:
> I seem to have an issue with users who copy-paste their usernames and
> passwords coping and pasting leading and trailing space characters.
> The obvious fix was to trim() the values that I receive, but I worry
> how that would affect users who use a space at the beginning or end of
> their password. Of course, if I trim() also when the user is setting
> his password then he will never know that his password is really 1
> digit shorter, but do I really want to do that? Thoughts? Thanks!
If users want to embed spaces in their passwords, well and good. But at
the beginning or end? No. Trim them. As mentioned elsewhere, I suspect
this is mostly because of copying and pasting.
Paul
--
Paul M. Foster
http://noferblatz.com
--- End Message ---
--- Begin Message ---
On Dec 28, 2010, at 8:52 AM, Dotan Cohen wrote:
> On Tue, Dec 28, 2010 at 15:27, Al <[email protected]> wrote:
>> Can't you simply specify the allowed characters that can be used for PWs and
>> usernames?
>>
>
> No, I hate when websites do that. It leads to less secure passwords,
> not more secure, and it is passing the burden of fixing the issue onto
> the user.
>
>
>> I always do, e.g., 6-8, case sensitive, alphanumerics, and the following
>> characters: "@, #, $, %, &, *, -".
>>
>> Then, I trim() and check the submitted PW for any exceptions to the rules.
>>
>
>
> I regularly use other characters in my passwords. Of the top of my
> head, I have passwords with the tilda, underscore, and exclamation
> point. Sites that don't let me use them don't get my business.
> Seriously. I once even switched banks twice in one week: once because
> the old bank's website did not work with Firefox in Fedora, and the
> second time because the new bank's website would not let me use an
> exclamation point in my password. I might be an extreme example, but
> it is behaviour that I do not agree with.
>
I completely agree with your method. I too, have switched banks and other
online services because of developer / programmer laziness.
--- End Message ---
--- Begin Message ---
On Tue, Dec 28, 2010 at 17:13, Paul M Foster <[email protected]> wrote:
> If users want to embed spaces in their passwords, well and good. But at
> the beginning or end? No. Trim them. As mentioned elsewhere, I suspect
> this is mostly because of copying and pasting.
>
A leading space in a password is a terrific defence against
accidentally entering the password at the CLI and having it saved to
history. I've done that, not noticing that I was getting an SSH error
instead of a password prompt, and had the password in the history of a
machine that I couldn't erase the history of.
Another defensive password method is to end the password with
"&lang=en" to foil poorly-written web apps who GET the submission
form. I don't want my password stored in a webserver logfile somewhere
as a querystring, so disguising part of the password as a GET variable
helps.
A password that takes advantage of both these features might be "
John123Lennon&lang=en" which is easy to type, easy to remember, very
long and contains a wide variety of characters. Trimming spaces would
_not_ be what a user of this password would want. And yes, I'm the OCD
geek with such passwords.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--- End Message ---
--- Begin Message ---
... And yes, I'm the OCD
geek with such passwords.
Dotan,
that is great! You made a dry topic hilarious! (on top of the
practical points you make.)
Thanks!
------------
Govinda
--- End Message ---
--- Begin Message ---
Hi.
I am currently looking into improving a system that (like many systems)
generate static content at runtime.
I have always been against generating static content at runtime and
believe static content should be generated by a cronjob or manually at
some idle time (if possible).
This will provide real static content (no PHP at all) that doesn't need
to be checked every time a request is made hence a huge performance
benefit is achieved.
A nice article on the issue:
http://zoompf.com/blog/2009/12/the-challenge-of-dynamically-generating-static-content
Quote: "The moral of the story is never make the user pay for your
laziness. Do not use the application tier of a website to dynamically
generate static content at runtime. Instead do it at publishing time or
even do it in a daily or hourly cron job. This approach allows you all
the advantages of using application logic without drastically reducing
the very web performance you were trying to improve in the first place!"
Sometimes however many pages are linked together and when working with
a system with hundreds or thousands of pages re-creating a lot of
content each night perhaps isn't always the best way to do things.
Especially if the content needs to be updated right away and can't wait
for the nightly cronjob to do its business.
To illustrate with a simple example..
A blog system with a menu that displays how many posts exists in each
category.
- Home
- About
- Tech (412)
- News (2030)
etc.
When a new page is added to the News category every single page in the
system needs to get updated in order for the menu to display the new
number (2031).
Some use a compromise to include only changing items (like the menu
in the above example), but that would mean using PHP and not serving
pure static content.
Others use "ugly" solutions like frames.
Care to share your experiences and recommendations on the issue?
Kind regards
---
Kim N. Lesmer
Programmer/Unix systemadministrator
Web : www.bitflop.com
E-mail : [email protected]
--- End Message ---
--- Begin Message ---
Care to share your experiences and recommendations on the issue?
It seems to me that you ask a great question, and ask it well.
I have worked on both kinds of systems. But I am not expert enough to
say anything definitively. Just one thought I had while thinking
about it:
How about: publish static content.. and for the changing menu number,
use Ajax instead of PHP include(s). Would that be any better? ...or
maybe it is effectively the same "dynamic" burden in the end?
------------
Govinda
--- End Message ---
