Subject | Re: [ib-support] date string format |
---|---|
Author | David K. Trudgett |
Post date | 2002-01-05T10:15:17Z |
On Saturday 2002-01-05 at 15:18:28 +0800, Andrew (CSSWA) wrote:
re-visited, but that is OT for this list, and has apparently been
earmarked for attention. I believe there's a list called
"ib-priorities" that could be used to discuss this. One thing to keep
in mind, though, is that proper threat analysis needs to be done, and
a solution designed around the analysis. Password length is only one
small link in the chain. As a small example, if passwords are
susceptible to sniffing over an unencrypted and not fully trusted
(i.e., untrusted) network link, the password length is a moot point.
On a related point, I would expect IB/FB to log unsuccessful logon
attempts (perhaps someone could confirm that -- if not, it's easily
tested). If your log monitor daemon notices 500,000 failed logins, it
should probably be sending a little note to the DB and system admins,
no? :-)
line of the body of this email (yyyy-mm-dd). Notice that there is no
potential for confusion using this format.
David Trudgett
> Hello all.I would agree that the security/authorisation framework needs to be
>
> > Because 8 characters is easy to crack, you're advised not to use
> > easily guessable words as passwords. Better to create completely
> > random combinations of letters and digits.
>
> (1) RE the 8-letter passwords... yikes. Sure, forcing alphanumeric
> variable-case random 8 letter passwords would get the most security
> out of 8 characters, but it still avoids the issue of brute force
> password attacks. I have no idea how difficult it may be to
> implement a brute force attack against interbase, locally or via
> internet, but I'd still like to have a larger password length
> reasonable for today's security expectations. To me, this seems to
> be about mid-level priority -- not urgent, but desirable asap. Is
> it going to be a problematic change?
re-visited, but that is OT for this list, and has apparently been
earmarked for attention. I believe there's a list called
"ib-priorities" that could be used to discuss this. One thing to keep
in mind, though, is that proper threat analysis needs to be done, and
a solution designed around the analysis. Password length is only one
small link in the chain. As a small example, if passwords are
susceptible to sniffing over an unencrypted and not fully trusted
(i.e., untrusted) network link, the password length is a moot point.
On a related point, I would expect IB/FB to log unsuccessful logon
attempts (perhaps someone could confirm that -- if not, it's easily
tested). If your log monitor daemon notices 500,000 failed logins, it
should probably be sending a little note to the DB and system admins,
no? :-)
>Try using ISO-8601 international standard date format, as in the first
> (2) Via IBconsole sql, the udf Date Of Week processed as
> udf_dow('1/4/2002') returns Friday (4th Jan, today). Is the format
> of mm/dd/yy (not our usual format here in Oz) hard-coded into the
> day_of_week udf?
line of the body of this email (yyyy-mm-dd). Notice that there is no
potential for confusion using this format.
David Trudgett