[clug] [OT] all text passwords == secure?

[Scott Ferguson]

On 27/08/12 22:23, Sam Couter wrote:
> Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:

<snipped>

> 
>> Most likely there is also a policy in place that locks out attempts
>> after a number of failures within a given time period.
> 
> Yes, which means the service desk is kept busy unlocking accounts all the
> time,

Which is *not* a reason to change the policy - it's the reason why
people should examine the cause of all those 'professionals' being
unable to manage the most basic elements of their "profession" - access.

You are right - those people, BU developers, require password resets
more often that anyone else. They also "fiddle" with hardware in breach
of their employment contract more often than any other group. eg. remove
hard drives from "unused" machines, insert them into "their" computer
for "personal backups" (with power supplies not rated for the additional
load), and bring their own computer devices into the workplace.  The
problem is psychological - the degree to which people don't abide by the
rules created for security is often determined by the degree to which
the person believes the rules should not apply to them.

That's not to say that most developers don't do the right thing. Never
the less - every years several are 'counselled' for license breaches
(putting music or movies onto work computers where all personal material
is supposed to be work related *and* be stored only on the network
shares), and one or two for more serious breaches (pirated software,
breaching network security). "risk" is not as important as "impact".
Those same developers have administrative access to their machines.

Bear in mind that the companies charged with support, and the company
that maintains the firewall, don't tell staff when the system has been
compromised.

> especially for developers who have accounts in production and
> development trust domains and applications that store authentication
> credentials (username and password) instead of a pre-authenticated token
> such as a Kerberos ticket. The limit should be much higher, possibly
> unlimited in the dev domain.

It has been in the past - there was even a time when that groups
password could be reset locally (self managed). For the reasons stated
above - that's no longer the case.


Same problem as stated before - the actions of a few are borne by many.
Not healthy. :-(

> 
>> I've seen lots of presentations for biometric and presence based
>> authentication systems... which are much hyped. But every one I've
>> looked at had gaping holes - and significantly higher costs.
> 
> Biometric systems have fundamental problems. Once they've been
> compromised, it's impossible to change the authentication secret. 

The presence based system we were given a presentation on took less than
half an hour to hijack. It didn't just have gaping holes the potential
impact if it was compromised was huge eg. it allowed the remote
monitoring of everyone (what could possibly go wrong). Despite blind
reliance on complexity (sells well, rarely works) the support system was
staffed by unskilled, low wage personel in a ridiculously low-tech
centre (their server had *telnet* and basic ftp access). One of the
features demonstrated was the ability to "phone in" which the sales rep
demonstrated - to which a good number of his audience dutifully, and
accurately, guessed his 4 digit PIN from across the room - and accessed
during the demonstration.

<snipped>

Kind regards.