On Sat, 30 Jul 2011 00:33:02 +0000 (UTC), Andrew Smallshaw
<andrews@sdf.lonestar.org> wrote:

>On 2011-07-29, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Fri, 29 Jul 2011 19:52:33 +0000 (UTC), Andrew Smallshaw
>><andrews@sdf.lonestar.org> wrote:
>>
>>>At that point I couldn't reuse an old password since thay were
>>>automatically black-listed (in other words, they were _not_ being
>>>irretrievably hashed) (...)
>>
>> While it may indicate that, the way it's usually done is to keep the
>> last N hashes, and prevent password that have the same hash from being
>> reused.  Obviously there's a chance of collisions, but a decent hash
>> of adequate size keeps that to a minimum.
>
>Not here, since the blacklisting was coupled with a "too much alike"
>test.  So, for example, if a previous password was "Password1" it
>would reject "Password2" as well.  I don't see how you can implement
>that without being able to recover the original password.


Usually you do a number of very short "hashes" to catch certain
conditions.  For example, you could sum the characters of the password
(perhaps mod some value), and insist that the old and new sum be at
least two different - that way you catch all the password1, password2,
password3... attempts.  You have to be careful to not end up storing
too much information when you do that.  Of course that can generate
false positives.

As I said, I don't know anything about the implementation in question,
and they could very well be doing it badly.

On 2011-07-29, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Fri, 29 Jul 2011 19:52:33 +0000 (UTC), Andrew Smallshaw
><andrews@sdf.lonestar.org> wrote:
>
>>At that point I couldn't reuse an old password since thay were
>>automatically black-listed (in other words, they were _not_ being
>>irretrievably hashed) (...)
>
> While it may indicate that, the way it's usually done is to keep the
> last N hashes, and prevent password that have the same hash from being
> reused.  Obviously there's a chance of collisions, but a decent hash
> of adequate size keeps that to a minimum.

Not here, since the blacklisting was coupled with a "too much alike"
test.  So, for example, if a previous password was "Password1" it
would reject "Password2" as well.  I don't see how you can implement
that without being able to recover the original password.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

On Fri, 29 Jul 2011 19:52:33 +0000 (UTC), Andrew Smallshaw
<andrews@sdf.lonestar.org> wrote:

>Those kind of precautions always strike me as counter-productive.
>One case in point was a former credit card provider who had all
>that kind of strong-password precautions, expired them every 90
>days and locked your account on the third unsuccessful attempt.
>The problem is that I may have only wanted to check my credit card
>online a couple of times a year at most.  In other words, I needed
>to change my password every time I logged in.  
>
>At that point I couldn't reuse an old password since thay were
>automatically black-listed (in other words, they were _not_ being
>irretrievably hashed) (...)


While it may indicate that, the way it's usually done is to keep the
last N hashes, and prevent password that have the same hash from being
reused.  Obviously there's a chance of collisions, but a decent hash
of adequate size keeps that to a minimum.

A problem with the one-way hashes is that they inherently reduce the
entropy in the passwords, since you're throwing some of that away to
make the process irreversible.  So there will always be multiple
passwords that hash to the same value.

Hi Andrew,

On 7/29/2011 12:52 PM, Andrew Smallshaw wrote:
> On 2011-07-28, Don Y<nowhere@here.com>  wrote:

>> <frown>   Yeah, something needs to be done about this:
>>
>> "Never use the same password for different accounts"
>> "Never write down your password"
>> "Never use an easy to guess (remember!) password"
>> "Never use less than 14 characters containing a mix of
>>      alpha, numeric, punctuation and differing cases."
>
> Those kind of precautions always strike me as counter-productive.
> One case in point was a former credit card provider who had all
> that kind of strong-password precautions, expired them every 90
> days and locked your account on the third unsuccessful attempt.
> The problem is that I may have only wanted to check my credit card
> online a couple of times a year at most.  In other words, I needed
> to change my password every time I logged in.

Automated systems for enforcing these sorts of policies are
silly.  All they effectively do is force you to come up with
(trivial) ways to get around their rules.  E.g., change
your "foo!Baz3" password to "goo@Caz4"... then "hoo#Daz5", etc.
I.e., all you are doing is making my life more difficult
and doing nothing to increase the security *on* my account.

I avoid most on-line accounts and insist on talking to
a real human being.  They verify the number I am calling
from coincides with the number from which I originally
authorized the card.  And, can ask me selective questions to
verify my identity -- hopefully better than a machine can!

> At that point I couldn't reuse an old password since thay were
> automatically black-listed (in other words, they were _not_ being
> irretrievably hashed) so the only practical portion was to record
> the password somewhere - surely counter-productive.  I think this
> kind of paranoid and truly impractical security has more to do with
> the card provider covering their own back than actually providing
> effective security.

Exactly!  Remember that their goal in all of this is to reduce
*their* costs by making it easier for you to interact with a machine
(even though you might have to spend *more* time on each such
transaction).  So, they want to do "enough" to NOT be accused of
being sloppy, etc.

> Another case in point was in a former government job.  90%+ of the
> material was only restricted but there was a small minority of
> confidential material.  In other words, not terribly sensitive
> stuff, but the government tends to be pretty hot on these things.
> Again, passwords expired every 90 days and the accounts were locked
> on the third unsuccessful attack.  This time passwords were
> machine-generated.  To give you some idea of how secure this "highly
> secure" system is in reality I once had to check everyone's desks
> at the end of the day for some missing papers.  I checked twelve
> desks and found passwords for nine accounts, hidden under keyboards
> or suchlike.  In other words, the real level of security was close
> to zero, since one thing those systems had going for them was a
> proper single-point sign on.  Once logged in, you had full access
> to _all_ services you were authorised for.

sex, passw0rd, admin, god, etc.  I am amazed at how often these
passwords actually *work*!

The problem with passwords is that they require too much effort
and discretion on the part of the user (password holder).  I'd
much prefer smartcard readers or their ilk... something where
I can carry a *token* for authentication.

I've settled on long passwords that are easy to remember
but contain unusual characters (not obvious ones like
using '@' as "at", '2' as "to", '4' as "for", etc.).
I also regularly watch the rainbow table builders to see
what limitations they impose on their tables to block
that (easy!) attack (at least on my PC's).

I routinely discard on-line accounts (email, etc.) so the
problem of changing passwords seldom presents itself.

[OTOH, these tools make it *really* easy to exploit naive
users... I always find it amusing to consider how the
"victim's" machine actually does ALL the work cracking
*their* password!  :-/ ]

On 2011-07-28, Don Y <nowhere@here.com> wrote:
>
> There are some "free" NNTP services (with limitations).

I've been using eternal-september.org for the last couple of years.
Free and the only real issue I've noticed is they don't carry binary
groups, but that isn't a problem at all for me.
 
><frown>  Yeah, something needs to be done about this:
>
> "Never use the same password for different accounts"
> "Never write down your password"
> "Never use an easy to guess (remember!) password"
> "Never use less than 14 characters containing a mix of
>     alpha, numeric, punctuation and differing cases."

Those kind of precautions always strike me as counter-productive.
One case in point was a former credit card provider who had all
that kind of strong-password precautions, expired them every 90
days and locked your account on the third unsuccessful attempt.
The problem is that I may have only wanted to check my credit card
online a couple of times a year at most.  In other words, I needed
to change my password every time I logged in.  

At that point I couldn't reuse an old password since thay were
automatically black-listed (in other words, they were _not_ being
irretrievably hashed) so the only practical portion was to record
the password somewhere - surely counter-productive.  I think this
kind of paranoid and truly impractical security has more to do with
the card provider covering their own back than actually providing
effective security.

Another case in point was in a former government job.  90%+ of the
material was only restricted but there was a small minority of
confidential material.  In other words, not terribly sensitive
stuff, but the government tends to be pretty hot on these things.
Again, passwords expired every 90 days and the accounts were locked
on the third unsuccessful attack.  This time passwords were
machine-generated.  To give you some idea of how secure this "highly
secure" system is in reality I once had to check everyone's desks
at the end of the day for some missing papers.  I checked twelve
desks and found passwords for nine accounts, hidden under keyboards
or suchlike.  In other words, the real level of security was close
to zero, since one thing those systems had going for them was a
proper single-point sign on.  Once logged in, you had full access
to _all_ services you were authorised for.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

On 07/28/2011 03:59 AM, Don Y wrote:
> On 7/27/2011 9:51 PM, bbhack wrote:
>> On 07/23/2011 04:56 PM, Don Y wrote:
>
>>> But why *use* google groups instead of a "real" news service?
>>>
>>> (sorry, I don't use anything but google search -- and that, DECREASINGLY
>>> so...)
>>
>> I'm using Clear at the moment. Previously TW, previously ATT. None offer
>> NNTP anymore (some time now).
>
> There are some "free" NNTP services (with limitations).
>
> Locally, smaller providers (typically those with UN*X services)
> will often give you access to an NNTP -- if not a complete *feed*
> (as well as shell access, etc.)
>
>> So, it's just one more expense to have real NNTP, but I found out, after
>> some effort, that low byte-count NNTP is real cheap. Just another
>> account and password, like you don't have too many already.
>
> <frown> Yeah, something needs to be done about this:
>
> "Never use the same password for different accounts"
> "Never write down your password"

Way OT, but whatever. A security expert once said to keep you passwords 
strong and different, write them down and put them in your wallet. I 
would agree, but I don't do that. I do keep a card at my desk, though. 
And they're not all strong and not all different.

> "Never use an easy to guess (remember!) password"
> "Never use less than 14 characters containing a mix of
> alpha, numeric, punctuation and differing cases."
>
> OK, yet every financial institution, internet service,
> retailer, etc. wants me to set up a *separate* account
> with them... just how much of this am I supposed to
> commit to memory? :>
>
> [I am actually amused at just how much of this cruft I
> *can* keep in my head!]

On Thu, 28 Jul 2011 08:04:11 -0400, Rich Webb
<bbew.ar@mapson.nozirev.ten> wrote:

>On Thu, 28 Jul 2011 06:44:46 -0500, Robert Wessel
><robertwessel2@yahoo.com> wrote:
>
>>On Thu, 28 Jul 2011 01:59:13 -0700, Don Y <nowhere@here.com> wrote:
>>
>>>On 7/27/2011 9:51 PM, bbhack wrote:
>>>> So, it's just one more expense to have real NNTP, but I found out, after
>>>> some effort, that low byte-count NNTP is real cheap. Just another
>>>> account and password, like you don't have too many already.
>>>
>>><frown>  Yeah, something needs to be done about this:
>>>
>>>"Never use the same password for different accounts"
>>>"Never write down your password"
>>>"Never use an easy to guess (remember!) password"
>>>"Never use less than 14 characters containing a mix of
>>>    alpha, numeric, punctuation and differing cases."
>>>
>>>OK, yet every financial institution, internet service,
>>>retailer, etc. wants me to set up a *separate* account
>>>with them... just how much of this am I supposed to
>>>commit to memory?  :>
>>>
>>>[I am actually amused at just how much of this cruft I
>>>*can* keep in my head!]
>>
>>
>>While a global authentication scheme has its attractions (and its
>>drawbacks), in the interim something like Password Safe can go a long
>>way to making the multitude of accounts and passwords problem
>>tractable:
>>
>>http://passwordsafe.sourceforge.net/
>
>There's also http://keepass.info/, another FOSS password keeper. A nice
>feature (that may be in Password Safe but I've never used that one) is
>that it can be set to clear the clipboard after X seconds, so that a
>copy-n-paste operation to use an account's password isn't vulnerable to
>a clipboard sniffer (or accidentally pasting the password somewhere else
>in the clear fifteen minutes later).


Password Safe is similar.  It locks the database (so you have to enter
the database password again) and clears the clipboard after the
configured interval, and usually clears the clipboard after you
minimize the app too.

I've not used Keepass, but there are a lot of nice features in PWS,
and I've used it for years.  I don't think I could live without
something like that - I've got nearly 300 entries in mine.

On Thu, 28 Jul 2011 06:44:46 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Thu, 28 Jul 2011 01:59:13 -0700, Don Y <nowhere@here.com> wrote:
>
>>On 7/27/2011 9:51 PM, bbhack wrote:
>>> So, it's just one more expense to have real NNTP, but I found out, after
>>> some effort, that low byte-count NNTP is real cheap. Just another
>>> account and password, like you don't have too many already.
>>
>><frown>  Yeah, something needs to be done about this:
>>
>>"Never use the same password for different accounts"
>>"Never write down your password"
>>"Never use an easy to guess (remember!) password"
>>"Never use less than 14 characters containing a mix of
>>    alpha, numeric, punctuation and differing cases."
>>
>>OK, yet every financial institution, internet service,
>>retailer, etc. wants me to set up a *separate* account
>>with them... just how much of this am I supposed to
>>commit to memory?  :>
>>
>>[I am actually amused at just how much of this cruft I
>>*can* keep in my head!]
>
>
>While a global authentication scheme has its attractions (and its
>drawbacks), in the interim something like Password Safe can go a long
>way to making the multitude of accounts and passwords problem
>tractable:
>
>http://passwordsafe.sourceforge.net/

There's also http://keepass.info/, another FOSS password keeper. A nice
feature (that may be in Password Safe but I've never used that one) is
that it can be set to clear the clipboard after X seconds, so that a
copy-n-paste operation to use an account's password isn't vulnerable to
a clipboard sniffer (or accidentally pasting the password somewhere else
in the clear fifteen minutes later).

-- 
Rich Webb     Norfolk, VA

On Thu, 28 Jul 2011 01:59:13 -0700, Don Y <nowhere@here.com> wrote:

>On 7/27/2011 9:51 PM, bbhack wrote:
>> So, it's just one more expense to have real NNTP, but I found out, after
>> some effort, that low byte-count NNTP is real cheap. Just another
>> account and password, like you don't have too many already.
>
><frown>  Yeah, something needs to be done about this:
>
>"Never use the same password for different accounts"
>"Never write down your password"
>"Never use an easy to guess (remember!) password"
>"Never use less than 14 characters containing a mix of
>    alpha, numeric, punctuation and differing cases."
>
>OK, yet every financial institution, internet service,
>retailer, etc. wants me to set up a *separate* account
>with them... just how much of this am I supposed to
>commit to memory?  :>
>
>[I am actually amused at just how much of this cruft I
>*can* keep in my head!]


While a global authentication scheme has its attractions (and its
drawbacks), in the interim something like Password Safe can go a long
way to making the multitude of accounts and passwords problem
tractable:

http://passwordsafe.sourceforge.net/

Don Y wrote:

> Hi Walter,
>
> On 7/27/2011 2:01 AM, Walter Banks wrote:
> >  A typical microwave implementation
> > that I am familiar with uses 40-60K of 8 bit processor code
> > for oven control and separate micro for display and keyboard.
>
> Is this a "typical microwave oven"?  Or, just one that you are
> familiar with?
>

I am familiar with two companies microwave oven product lines. Both are
large companies with a range of models and features. Both ship products
world wide.  My typical comment was a statistical mean of the products
they ship. I am familiar with both their low end product and high end
products. A the low end software has few user features but still
requires oven control for reasonable product life and safety. The high
end models implement indirect instrumentation to measure contents and
data bases of cooking profiles.

Regards,


w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com