On Fri, 10 Jan 2003, Paul M Fleming wrote:
> Personally I have issues with dumping the contents of a password cache
> to a file. Especially in this case, they WILL be stored in cleartext. I
> had planned on keeping somes stats (hits,misses,etc)
Fair enough. Even if you don't dump passwords, it mi
Good point.. I don't have to store the cleartext version in order to do
the compare.. if i save the hash and just hash what the user submits and
compare them that would be sufficient.. just have to keep the cleartext
password long enough to do an actual authentication if need be..
Jeremy Rumpf w
I always hashed the password as soon as they entered the cache. So the
checkpoint dump would contain binary MD5, SHA hashes etc. They're not clear
text per say, but I can see why some would not find even that ideal.
Cheers,
Jeremy
On Friday 10 January 2003 11:07 am, Paul M Fleming wrote:
> Pers
Personally I have issues with dumping the contents of a password cache
to a file. Especially in this case, they WILL be stored in cleartext. I
had planned on keeping somes stats (hits,misses,etc)
Jeremy Rumpf wrote:
>
> > This whole idea sounds great, especially as I'd expect a lot of the
> > au
> This whole idea sounds great, especially as I'd expect a lot of the
> authentication load to come from a small number of users with their
> clients set to check mail every few minutes.
>
> For debugging it would help if there was a way to force a flush of the
> entire cache, and one to dump its c
My current thinking is to use
http://www.ossp.org/pkg/lib/mm/ for the shared memory stuff and
&
http://256.com/sources/table/ for the hash table
I haven't had a chance to look at:
ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz
yet
Igor Brezac wrote:
>
> On Thu, 9 Jan 20
On Thu, 9 Jan 2003, Jeremy Rumpf wrote:
>
> On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote:
> > Timing out the passwords is simple ( I think ) I would store the time
> > when the entry is added and force a reauth if the password has been
> > cached longer than a timeout (for example o
Paul M Fleming wrote:
> Timing out the passwords is simple ( I think ) I would store the time
> when the entry is added and force a reauth if the password has been
> cached longer than a timeout (for example one hour ). That forces a
> reauth at least every timeout period of time. If an entry isn'
On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote:
> Timing out the passwords is simple ( I think ) I would store the time
> when the entry is added and force a reauth if the password has been
> cached longer than a timeout (for example one hour ). That forces a
> reauth at least every ti
Paul M Fleming wrote:
Timing out the passwords is simple ( I think ) I would store the time
when the entry is added and force a reauth if the password has been
cached longer than a timeout (for example one hour ). That forces a
reauth at least every timeout period of time. If an entry isn't in th
Correct..
John Alton Tamplin wrote:
>
> Paul M Fleming wrote:
>
> >Timing out the passwords is simple ( I think ) I would store the time
> >when the entry is added and force a reauth if the password has been
> >cached longer than a timeout (for example one hour ). That forces a
> >reauth at lea
Timing out the passwords is simple ( I think ) I would store the time
when the entry is added and force a reauth if the password has been
cached longer than a timeout (for example one hour ). That forces a
reauth at least every timeout period of time. If an entry isn't in the
cache (or if it is dif
Related to this thread... I am considering writing a generic cache layer
into saslauthd to lessen the load on the backend auth mechanism. My idea
is to implement a hash table in shared memory and use that to cache the
userid,password etc with a timeout. This should lighten the load ..
Comments? Ide
On Thu, 9 Jan 2003, Rob Siemborski wrote:
> Done.
>
> Someone should sanity-check the documentation I put in LDAP_SASLAUTHD.
>
Looks good.
I do not see when '2. There is no cost to staying bound as a named user'
would be false. Maybe for backends other then ldbm|bdb. It will cause
extra disco
Done.
Someone should sanity-check the documentation I put in LDAP_SASLAUTHD.
-Rob
On Thu, 9 Jan 2003, Igor Brezac wrote:
>
> On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > On Wed, 1 Jan 2003, Igor Brezac wrote:
> >
> > > On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> > > [...]
> > > > Can a
On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
> On Wed, 1 Jan 2003, Igor Brezac wrote:
>
> > On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> > [...]
> > > Can anyone offer advice on tuning the saslauthd pool? Are there particular
> > > options, either on the command line or in saslauthd.conf, which
On Wed, 1 Jan 2003, Kervin L. Pierre wrote:
> Maybe you should seriously consider moving from back-shell to back-perl,
> which you can optimize much more and is probably quicker right of the
> bat, since it does not spawn a separate process for the interpreter.
>
> Better still, have you though
On Wed, 1 Jan 2003, Igor Brezac wrote:
> On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> [...]
> > Can anyone offer advice on tuning the saslauthd pool? Are there particular
> > options, either on the command line or in saslauthd.conf, which I should
> > be looking at?
>
> Try using 'ldap_auth_met
--On Wednesday, January 01, 2003 9:21 PM -0500 Igor Brezac <[EMAIL PROTECTED]>
wrote:
[...]
If you are on Solaris, I highly recommend the doors IPC method over the
UNIX socket method, since we began to see very bizarre problems under
load.
You might run into problems if you use ldap api and door
On Wed, 1 Jan 2003, Rob Siemborski wrote:
> On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > Since it's hard to predict peak usage, I'm tempted to run the daemon with
> > the -n0 option so it can spawn as required. However, a colleague has
> > pointed out that if something blows up then spawn-on
[EMAIL PROTECTED] wrote:
directory it's binding to is quite slow (it's actually a slapd instance
running a shell backend which routes bind requests to different places
depending on the usercode - don't ask...). Because saslauthd makes
Maybe you should seriously consider moving from back-shell to
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> Since it's hard to predict peak usage, I'm tempted to run the daemon with
> the -n0 option so it can spawn as required. However, a colleague has
> pointed out that if something blows up then spawn-on-demand could kill the
> server - with a fixed-size p
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> I've just upgraded to imapd 2.1.11, and while it's going fine so far I'm a
> bit concerned about how it will cope under load when our students return.
>
> The problem is that I'm using the saslauthd native LDAP mechanism, and the
> directory it's bind
I've just upgraded to imapd 2.1.11, and while it's going fine so far I'm a
bit concerned about how it will cope under load when our students return.
The problem is that I'm using the saslauthd native LDAP mechanism, and the
directory it's binding to is quite slow (it's actually a slapd instance
ru
24 matches
Mail list logo
