Often when one registers on different web sites around the world, there is a
pretty hard limitation on what characters I am allowed to use in my username and
password. Why is that? What limitations should I put on my customers' usernames
and passwords if I just want to store it in an SQL or Access database? And why?
--
Best regards,
Tomas Eklund
On Wed, 16 Feb 2005 21:48:46 +0100, "Tomas Eklund"
>Often when one registers on different web sites around the world, there is a
>pretty hard limitation on what characters I am allowed to use in my username and
>password. Why is that? What limitations should I put on my customers' usernames
>and passwords if I just want to store it in an SQL or Access database? And why?
If you're rolling your own, allow whatever characters you want, with
the exception of those that may confuse your database. High ASCII,
quotes, etc. can cause issues, but if you want to allow others that's
fine.
If you're using an authentication scheme dependent on something
outside of your control, such as Windows accounts, you have to stick
with what they allow.
Jeff
<<
Often when one registers on different web sites around the world, there
is a pretty hard limitation on what characters I am allowed to use in my
username and password. Why is that? What limitations should I put on my
customers' usernames and passwords if I just want to store it in an SQL
or Access database? And why?
>>
The most common password limitations I've seen recently are to have a
minimum number of characters and to require at least one number
character in the password.
And the reason is simply that passwords with the above characteristics
are harder for someone to guess or crack by the brute force method of
trying lots of different passwords.
And think about it, passwords are often words, and some hacker-types
even have lists of common password words.
And that brings to mind that when thinking of a password to use, try not
to use a regular word but instead perhaps parts of words such as
initials (but not your own initials as that might be too easy for
someone who knows you to guess).
Best regards,
J. Paul Schmidt, Freelance ASP Web Developer
http://www.Bullschmidt.com
ASP Design Tips, ASP Web Database Demo, Free ASP Bar Chart Tool...
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
The important point is really the number of ciffers/digits in the password:
the more the better. But generally a six-letter lowercase combination,
randomly generated should be OK as it allows for 308915776 different
passwords. You can include some VBS code to automatically generate
passwords, but if you are running a site with heavy duty security, you
should consider running such password generation against a database in order
to avoid duplicates (however unlikely that might be).
TB
"Tomas Eklund"
news:O2OSBlGFFHA.3728@TK2MSFTNGP14.phx.gbl...
> Often when one registers on different web sites around the world, there is
> a pretty hard limitation on what characters I am allowed to use in my
> username and password. Why is that? What limitations should I put on my
> customers' usernames and passwords if I just want to store it in an SQL or
> Access database? And why?
>
> --
> Best regards,
> Tomas Eklund
>
"TB"
news:un3U8%23QFFHA.2756@TK2MSFTNGP15.phx.gbl...
: The important point is really the number of ciffers/digits in the
password:
: the more the better. But generally a six-letter lowercase combination,
: randomly generated should be OK as it allows for 308915776 different
: passwords. You can include some VBS code to automatically generate
: passwords, but if you are running a site with heavy duty security, you
: should consider running such password generation against a database in
order
: to avoid duplicates (however unlikely that might be).
Whatever chosen is not the only concern. Allowing someone unlimited tries
to guess the password would mean it could be attacked by brute force, not to
mention a dictionary attack after a custom dictionary attack where common
passwords are attempted, and two I really like to use [only in a controlled
test environment] are my Hungarian Notation common/uncommon dictionary
attack and my substitution common/uncommon dictionary attack. If anyone has
unlimited tries, then at the very least a brute force attack can be tried
against the site. A dictionary attack, if successful, can gain access in
minutes, if not seconds whereas a brute force might take days. However, 6
lowercase only characters is only adequate if the number of tries are
limited.
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Of course, the more security the better, it is really a question of
resources versus sensitivity of the content. So yes, one could add a feature
whereby an account would be disabled after a certain of unsuccessful tries.
That on the other would expose the site to vandalism because a massive
attack could lock out a lot of users. Another posibility is to require
reproduction of character sequence included a random graphic element (I
forget the technical term for it). In that way, you can prevent automated
attacks.
TB
"Roland Hall"
news:ut4sgvSFFHA.1188@tk2msftngp13.phx.gbl...
> "TB"
> news:un3U8%23QFFHA.2756@TK2MSFTNGP15.phx.gbl...
> : The important point is really the number of ciffers/digits in the
> password:
> : the more the better. But generally a six-letter lowercase combination,
> : randomly generated should be OK as it allows for 308915776 different
> : passwords. You can include some VBS code to automatically generate
> : passwords, but if you are running a site with heavy duty security, you
> : should consider running such password generation against a database in
> order
> : to avoid duplicates (however unlikely that might be).
>
> Whatever chosen is not the only concern. Allowing someone unlimited tries
> to guess the password would mean it could be attacked by brute force, not
> to
> mention a dictionary attack after a custom dictionary attack where common
> passwords are attempted, and two I really like to use [only in a
> controlled
> test environment] are my Hungarian Notation common/uncommon dictionary
> attack and my substitution common/uncommon dictionary attack. If anyone
> has
> unlimited tries, then at the very least a brute force attack can be tried
> against the site. A dictionary attack, if successful, can gain access in
> minutes, if not seconds whereas a brute force might take days. However, 6
> lowercase only characters is only adequate if the number of tries are
> limited.
>
"TB" wrote in message news:unp5S5TFFHA.1924@TK2MSFTNGP14.phx.gbl...
: Of course, the more security the better, it is really a question of
: resources versus sensitivity of the content.
I disagree that sensitivity of the content should be a factor. That's like
saying, "Well, they broke in and stole my TV that didn't work so it's not
that big a deal." If you had a cheap house with contents of not much value,
if someone burned down your house, would it make any difference of the
content within? You still have to rebuild and you're down until then.
I've heard that argument a lot. "Why would anyone want to break into our
system? We don't have anything worth taking." Two problems with that
argument:
1. They may not know what you have so there is no reason for them not to
try.
2. They may not want your data but they also may not want you to have it
either. They could just be destructive.
: So yes, one could add a feature
: whereby an account would be disabled after a certain of unsuccessful
tries.
: That on the other would expose the site to vandalism because a massive
: attack could lock out a lot of users.
I wouldn't necessarily lock the account but a delay would be helpful or
possibly an email being generated, once, if the account is locked out to
unlock it, as in the case of forgetting one's password.
There has to be a medium between security and ease of use. If it's too
difficult to use for legitimate users or too much of an inconvenience, then
the security precautions in place could effectively create a DoS. (O:=
: Another posibility is to require
: reproduction of character sequence included a random graphic element (I
: forget the technical term for it). In that way, you can prevent automated
: attacks.
Yes, a random graphic element that cannot be screen-scraped appears to be
popular now. The downside is sometimes you cannot even tell what the
characters are as with one I just used today with MSFT. I got it wrong
twice. The attack on this type of protection will not be a frontal attack
at the graphics. And, none of this will protect you from a DoS or DDoS,
smurf, fraggle, etc. but do tend to discourage automated attempts of brute
force.
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
A good password policy should be combined with a good user name ditto. If
the user name is also a bit hard to guess, then you multiply the
diffulculties for the intruder.
Also, another good policy is to set an expiry date for passwords.
As for your observations about setting priorities, it is impossible not to
agree with you in principle. However, the plain reality is that very often a
business invests in a website just as they budget for art on the walls and
green potted plants. As most independent developers know, that allocation is
often not in proportion with the amount of work required for the development
of the site. And unless your customer is a bank (unlikely because they tend
to have their own salaried IT staff), then s/he will favor essentials such
as Flash and streaming video instead of boring subjects like the one we are
discussing now.
After all the greatest friend of the hacker is the company boss, who still
uses his daughter's name as the password to access the accounting system....
TB
"Roland Hall"
news:uG8dXDUFFHA.628@TK2MSFTNGP15.phx.gbl...
> "TB" wrote in message news:unp5S5TFFHA.1924@TK2MSFTNGP14.phx.gbl...
> : Of course, the more security the better, it is really a question of
> : resources versus sensitivity of the content.
>
> I disagree that sensitivity of the content should be a factor. That's
> like
> saying, "Well, they broke in and stole my TV that didn't work so it's not
> that big a deal." If you had a cheap house with contents of not much
> value,
> if someone burned down your house, would it make any difference of the
> content within? You still have to rebuild and you're down until then.
>
> I've heard that argument a lot. "Why would anyone want to break into our
> system? We don't have anything worth taking." Two problems with that
> argument:
>
> 1. They may not know what you have so there is no reason for them not to
> try.
> 2. They may not want your data but they also may not want you to have it
> either. They could just be destructive.
>
> : So yes, one could add a feature
> : whereby an account would be disabled after a certain of unsuccessful
> tries.
> : That on the other would expose the site to vandalism because a massive
> : attack could lock out a lot of users.
>
> I wouldn't necessarily lock the account but a delay would be helpful or
> possibly an email being generated, once, if the account is locked out to
> unlock it, as in the case of forgetting one's password.
>
> There has to be a medium between security and ease of use. If it's too
> difficult to use for legitimate users or too much of an inconvenience,
> then
> the security precautions in place could effectively create a DoS. (O:=
>
> : Another posibility is to require
> : reproduction of character sequence included a random graphic element (I
> : forget the technical term for it). In that way, you can prevent
> automated
> : attacks.
>
> Yes, a random graphic element that cannot be screen-scraped appears to be
> popular now. The downside is sometimes you cannot even tell what the
> characters are as with one I just used today with MSFT. I got it wrong
> twice. The attack on this type of protection will not be a frontal attack
> at the graphics. And, none of this will protect you from a DoS or DDoS,
> smurf, fraggle, etc. but do tend to discourage automated attempts of brute
> force.
>
> --
> Roland Hall
> /* This information is distributed in the hope that it will be useful, but
> without any warranty; without even the implied warranty of merchantability
> or fitness for a particular purpose. */
> Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
> WSH 5.6 Documentation -
> http://msdn.microsoft.com/downloads/list/webdev.asp
> MSDN Library - http://msdn.microsoft.com/library/default.asp
>
>