On Fri, 2002-04-26 at 20:27, martin f krafft wrote:
> never say impossible.
Quite. Way too many people will click continue to all the "this
certificate is not certified by anyone trusted" and "this certificate
certifies a different site" warnings.
Most people would click continue if their browse
On Fri, 2002-04-26 at 20:27, martin f krafft wrote:
> never say impossible.
Quite. Way too many people will click continue to all the "this
certificate is not certified by anyone trusted" and "this certificate
certifies a different site" warnings.
Most people would click continue if their brows
Well, yes... you're right !
** Never say impossible **
On Sat, 2002-04-27 at 02:27, martin f krafft wrote:
> also sprach eim <[EMAIL PROTECTED]> [2002.04.26.1757 +0200]:
> > With https data will be encripted and it's impossible to
> > find out login and password because they're not sent over
> >
Well, yes... you're right !
** Never say impossible **
On Sat, 2002-04-27 at 02:27, martin f krafft wrote:
> also sprach eim <[EMAIL PROTECTED]> [2002.04.26.1757 +0200]:
> > With https data will be encripted and it's impossible to
> > find out login and password because they're not sent over
>
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.27.2120 +0200]:
> > you know their algorithm against MAC table overflow?
> No i dont.. I would be very interrested in reading about it, if you know of
> a link.. Im sure that it would be possible to enforce some level of
> security..
it's quite s
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.27.2120 +0200]:
> > you know their algorithm against MAC table overflow?
> No i dont.. I would be very interrested in reading about it, if you know of
> a link.. Im sure that it would be possible to enforce some level of
> security..
it's quite
Gareth Bowker wrote:
>If someone's already logged in, and they visit a webpage on the same domain
>which asks for a username and password for the same realm as the one used
to
>log in, the browser will send the username/password pair without asking the
>user for any confirmation.
>At least I assu
Gareth Bowker wrote:
>If someone's already logged in, and they visit a webpage on the same domain
>which asks for a username and password for the same realm as the one used
to
>log in, the browser will send the username/password pair without asking the
>user for any confirmation.
>At least I ass
Steve Mickeler wrote:
>
> Trust not in switches.
>
> They too can be easily manipulated unless you have locked them down at a
> mac address and port level.
>
> 'apt-get install dsniff' ; 'man arpspoof'
Of course, which is one of the things I had in mind when I said:
> > topology. Switches tend
On Sat, Apr 27, 2002 at 03:32:45AM +0200, martin f krafft wrote:
> also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]:
> > Second more, if your users are allowed to have pages on the same
> > address as the login system, the browser can, without much effort,
> > be tricked into givi
Steve Mickeler wrote:
>
> Trust not in switches.
>
> They too can be easily manipulated unless you have locked them down at a
> mac address and port level.
>
> 'apt-get install dsniff' ; 'man arpspoof'
Of course, which is one of the things I had in mind when I said:
> > topology. Switches ten
On Sat, Apr 27, 2002 at 03:32:45AM +0200, martin f krafft wrote:
> also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]:
> > Second more, if your users are allowed to have pages on the same
> > address as the login system, the browser can, without much effort,
> > be tricked into giv
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]:
> Second more, if your users are allowed to have pages on the same
> address as the login system, the browser can, without much effort,
> be tricked into giving away your systems username and password to
> a personal user page...
also sprach eim <[EMAIL PROTECTED]> [2002.04.26.1757 +0200]:
> With https data will be encripted and it's impossible to
> find out login and password because they're not sent over
> the net in a clear way.
never say impossible.
--
martin; (greetings from the heart of the sun.)
\__
On Fri, Apr 26, 2002 at 07:55:06PM +0200, Dan Faerch wrote:
> You should be aware, that when you use normal .htaccess protection,
> browser never logout..With eg. Internet Explorer, all intances of IE
> have to be closed to make the browser forget the login..
Actually, I think instances of IE tha
also sprach Dan Faerch <[EMAIL PROTECTED]> [2002.04.26.1955 +0200]:
> Second more, if your users are allowed to have pages on the same
> address as the login system, the browser can, without much effort,
> be tricked into giving away your systems username and password to
> a personal user page...
also sprach eim <[EMAIL PROTECTED]> [2002.04.26.1757 +0200]:
> With https data will be encripted and it's impossible to
> find out login and password because they're not sent over
> the net in a clear way.
never say impossible.
--
martin; (greetings from the heart of the sun.)
\_
On Fri, Apr 26, 2002 at 07:55:06PM +0200, Dan Faerch wrote:
> You should be aware, that when you use normal .htaccess protection,
> browser never logout..With eg. Internet Explorer, all intances of IE
> have to be closed to make the browser forget the login..
Actually, I think instances of IE th
o i hope im not
repeating anything already said)
- Dan Faerch
A/S ScanNet
(Denmark)
- Original Message -
From: "eim" <[EMAIL PROTECTED]>
To: "Schusselig Brane" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, April 26, 2002 5:57 PM
Subject: Re: A more secure form of .h
o i hope im not
repeating anything already said)
- Dan Faerch
A/S ScanNet
(Denmark)
- Original Message -
From: "eim" <[EMAIL PROTECTED]>
To: "Schusselig Brane" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 5:57 PM
Subject
Hallo Brane,
I'm actually a K-13 student, and so in my 'strategic'
position I'm on both sides, admin of debian box and 3v1l cracker :)
No, well.. I was just kidding, I have really better things to
do than actually cracking Debian boxes in pubblic environments,
but anyway I what do you think about
Hallo Brane,
I'm actually a K-13 student, and so in my 'strategic'
position I'm on both sides, admin of debian box and 3v1l cracker :)
No, well.. I was just kidding, I have really better things to
do than actually cracking Debian boxes in pubblic environments,
but anyway I what do you think abou
Trust not in switches.
They too can be easily manipulated unless you have locked them down at a
mac address and port level.
'apt-get install dsniff' ; 'man arpspoof'
> Another option would be to run switches instead of normal hub or bus
> topology. Switches tend not to allow other nodes on a n
Tom Dominico wrote:
>
> Hello all,
>
> I have written some php-based internal systems for our users. Users are
> required to authenticate to access this system, and their login
> determines what they are allowed to do within the system. I am
> concerned that their logging in with cleartext pass
Trust not in switches.
They too can be easily manipulated unless you have locked them down at a
mac address and port level.
'apt-get install dsniff' ; 'man arpspoof'
> Another option would be to run switches instead of normal hub or bus
> topology. Switches tend not to allow other nodes on a
Tom Dominico wrote:
>
> Hello all,
>
> I have written some php-based internal systems for our users. Users are
> required to authenticate to access this system, and their login
> determines what they are allowed to do within the system. I am
> concerned that their logging in with cleartext pas
You might want to take a look at using digest authentication, which sends a MD5
digest of the pasword instead of the actual password.
http://httpd.apache.org/docs/howto/auth.html
> I have written some php-based internal systems for our users. Users are
> required to authenticate to access this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I am wondering if any of you have had similar problems. What is a more
> secure way for people to login? Is SSL an option, and if so, how do I
> go about using it? Do I have to purchase a certificate? Or is there
> some other option? Finally, sh
Hello all,
I have written some php-based internal systems for our users. Users are
required to authenticate to access this system, and their login
determines what they are allowed to do within the system. I am
concerned that their logging in with cleartext passwords is a security
risk. I work i
You might want to take a look at using digest authentication, which sends a MD5 digest
of the pasword instead of the actual password.
http://httpd.apache.org/docs/howto/auth.html
> I have written some php-based internal systems for our users. Users are
> required to authenticate to access this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I am wondering if any of you have had similar problems. What is a more
> secure way for people to login? Is SSL an option, and if so, how do I
> go about using it? Do I have to purchase a certificate? Or is there
> some other option? Finally, s
Hello all,
I have written some php-based internal systems for our users. Users are
required to authenticate to access this system, and their login
determines what they are allowed to do within the system. I am
concerned that their logging in with cleartext passwords is a security
risk. I work
32 matches
Mail list logo
