(RADIATOR) FYI - Looks like list server is on ORBS RBL

Kevin Wormington kworm at sofnet.com
Fri May 18 09:18:12 CDT 2001


Just noticed that messages from the Radiator list are coming in flagged as
RBL filtered from input.orbs.org:

[logs]# rblcheck 209.61.182.19
not RBL filtered by blackholes.mail-abuse.org
not RBL filtered by relays.mail-abuse.org
not RBL filtered by dialups.mail-abuse.org
RBL filtered by inputs.orbs.org
not RBL filtered by outputs.orbs.org

[logs]# host 209.61.182.19
19.182.61.209.IN-ADDR.ARPA domain name pointer server1.open.com.au

-----Original Message-----
From: Ingvar Berg (EIP) <Ingvar.Berg at eip.ericsson.se>
To: Radiator List <radiator at open.com.au>
Date: Friday, May 18, 2001 3:09 AM
Subject: [UCE RBL] RE: (RADIATOR) CHAP


>> -----Original Message-----
>> From: Mariano Absatz [mailto:lradius at pert.com.ar]
>> Sent: den 16 maj 2001 16:13
>> To: Ingvar Berg (EIP)
>> Cc: Radiator List
>> Subject: RE: (RADIATOR) CHAP
>>
>>
>> El 16 May 2001, a las 9:08, Ingvar Berg (EIP) escribió:
>>
>> > Or rather: you have to be able to decrypt them in Radiator, before
>> > using them. I'm not sure if you can do this with a hook, or if you
>> > need to hack the basic code in Radiator (i.e. persuade Mike
>> or Hugh to
>> > do some fun coding...)
>> or DIY :-)... but the point here is that most of the
>> encryption schemes
>> used for storing passwords are one way hash fucntions (one
>> way beeing the
>> key point here).
>
>=> You need to have control over this as well!
>>
>> You can't (without a considerable computational effort far beyond an
>> authentication server) get the original password from the
>> encrypted one.
>>
>> If you were to use a two way encryption scheme, it would have
>> to encrypt
>> and decrypt with the same key (if it uses a symmetric
>> algorithm like DES,
>> DES3, or the like) or encrypt with one key and decrypt with
>> another, both
>> generated as a pair (conventionally, one is supposed to be
>> public and the
>> other private).
>
>There are several good symmetrical encryption algorithms, yepp.
>>
>> The point is that this way, you should put the (master)
>> decryption key
>> "open" in the radiator config file, so you just moved the
>> weak point to
>> another place.
>
>You could keep the key inside your crypto-accelerator box
>>
>> Now, if you, for instance, keep the passwords in a public
>> open database
>
>You should restrict access to it as much as possible anyway, of course.
>
>/Ingvar
>
>> (or LDAP tree or whatever) where anyone can see it and you
>> can keep you
>> radiator configuration file really secure (i.e. mode 400 root owned
>> inside a mode 500 root owned directory and a really controlled set of
>> trustable people knowing the root password), you (or Mike)
>> could do it.
>>
>===
>Archive at http://www.open.com.au/archives/radiator/
>Announcements on radiator-announce at open.com.au
>To unsubscribe, email 'majordomo at open.com.au' with
>'unsubscribe radiator' in the body of the message.
>

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list