On 2015-01-12 08:24, Joel Rees wrote:
On Mon, Jan 12, 2015 at 7:32 AM, Iain M Conochie <i...@thargoid.co.uk>
wrote:
On 10/01/15 20:31, Brian wrote:
By all means advocate and use ssh keys. But at least provide some
substantial reason for spurning password login for that particular
situation. A blanket "don't use passwords" or "keys are better"
doesn't cut
it.
There are 3 (current) factors in authentication:
According to some models.
Care to enlighten me about others?
1. What the user knows
Knowledge is a thing which is had. It is potentially easy to
duplicate, in smal pieces. The choice of which piece is used is
hopefuly not so easily duplicated. This is the first assumed weakness
of passwords, that most people are lazy about the choice.
While it is possible to enforce certain password policies (e.g. must use
capital letters, numbers, symbols etc) these
do not necessarily dictate a secure password. I guess if I know you
phone number, if it is stored in my phone I have
it as well. Someone steals my phone they now also know and have your
number. If I do not add it to my phone, do I still
have it?
2. What the user has
Typical example is a bank card. Unfortunately, this is easy to
duplicate, if one is not careful about where one uses it. (ATM
machines where the front panel has been augmented by atackers, and the
reader slot has a second reader hiding in front of the real reader
provide one example.)
Physical keys, like the key to your front door or to the safe deposit
box, are another example.
Yup - I agree with this.
3. What the user is
Try to define that in a way useful to authentication, without invoking
either of the above concepts.
These increase in security as you go higher up the number.
How do prove that?
Knowledge is easier to duplicate than a physical item. You mentioned the
ATM attack.
That requires particular equipment to successfully orchestrate, and in
fact many
ATM's have been modified to not allow said equipment to function.
Of course, with the advent of 3D printing, duplicating physical items is
much easier that
it used to be.
How do you define security?
I don't need to. There is already a definition in English for this:
http://dictionary.cambridge.org/dictionary/british/security
So (assuming the
implementation is secure
Is "secure" here related to security above?
Secure as in the implementation has as close to 0 defects as possible.
) my fingerprint (being something I am)
You sure it's not something you have?
Nope - I am pretty sure it is something I am, within the context of the
above statement.
is more
secure than a password.
Unless someone chops your hand off to steal your BMW.
Again - implementation. Is the hand warm? Is there a pulse?
Also, an ssh-key (being something I have
Now there's an interesting assertion. It seems reasonable, if one
accepts certain implicit, arbitrary boundaries between the three
classes of tokens invoked above.
-- seems reasonable --
) is more
secure than a password.
And, yet, it is no more secure than the user account on the machine in
which it is stored.
OK sure - but we are discussing how to authenticate to an account right?
(Noting, not coincidentally, that the computer storage device acts as
a memory proxy.)
In each case we have the _implementation_
among other things
Please expand on other things
to let us down. #1 is up to the
user whereas #2 and #3 are up to the programmer.
I can think of a number of ways in which what you appear to be talking
about as something you have and something you are are as much under
control of the user as under control of the programmer.
Something you have and something you are have to be digitised, to
produce a
token that can be used to prove your identity to a computer system. That
is
part of the implementation.
Who do you trust ;)
I would prefer that we all learn to program.
I would prefer that no-one would try and break into my machines to be
honest, but we
all know that is not going to happen any time soon.
Cheers
Iain
--
Joel Rees
The only truly secure computer is the one that you wrote all the OS
and application code for.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/23baaf9183378cac13fcbef4f7762...@thargoid.co.uk
