[Cryptography] Fwd: Fwd: Re: A two key file/program

[Allen Schaaf]

On 5/17/2019 4:32 PM, Ángel wrote:
> On 2019-05-16 at 19:00 -0700, Allen Schaaf wrote:
>> The goal for the credit union is to encrypt login information
>> used by the staff.
> No, no, no. Don't do that.
>
> The login credentials of your users shall only be known by 
> them. Full
> stop.
>
> Letting other people know the password of the users makes auditing
> unnecessary hard.
>
> Suppose you had a rogue employee, and you find out. You are 
> suing him
> for the amount of money he stole, while he sues you for improper
> dismissal, claim it is all made up since the business needed a 
> scapegoat
> in order to please the shareholders...
> The company shows evidence that someone logged in with his account
> performed a number of fraudulent transactions.
> Who could log in as such account? The employee... and his bosses.
>
>
> The problem you really want to solve is «The manager/CEO and 
> assistant
> manager need to enable access to each account if needed»
>
> How is every other company solving this very same problem?
> You have a central authentication server (usually a Microsoft 
> Active
> Directory). Every time there is a need to log in into a host, it
> verifies the credentials. This allows it to verify that 
> passwords follow
> the given policy about renewal, lock out bruteforcing attempts,
> centrally log accesses, disable access for a user on just one 
> place when
> he leaves...
>
> Now, let's suppose that Fred is away on vacation while there's a
> pressing need to get a copy of the draft of a new policy stored 
> on his
> Desktop (while he was developing it), due to a new regulation 
> requiring
> you to implement it by the end of the week.
>
> An administrator would then reset the password of this user to 
> a new
> one, allowing you to log in to his account, *with no knowledge 
> of the
> password he was using*. At the same time, this action would 
> create the
> proper audit trail showing who performed the password reset on the
> account.
>
>
> It's safer and much more simple.
>
> Additionally, it's generally recommended that each user have only a
> single login, rather than six or seven (!), which simplifies user
> management.
>
>
> Best regards
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
(Sorry folks, I forgot to include the mailing list when replying.)

-------- Forwarded Message --------
Subject: 	Re: [Cryptography] A two key file/program
Date: 	Sat, 8 Jun 2019 18:26:14 -0700
From: 	Allen Schaaf <netsecurity at sound-by-design.com>
To: 	Ángel <angel at crypto.16bits.net>



Hi Ángel,

If we do not have access to the a potentially rouge employee's 
access to the various systems used by the credit union there 
would be no way to find out what crookedness they might have 
committed.

An employee is required to take a minimum of one week vacation 
per year, in the USA, to help with auditing process. If we can't 
access their computer and the various normal files and external 
systems used then we can't do an in depth audit.

The audit functionality is particularly important for upper level 
management as that is where most crookedness happens.

As to the number of login credentials, we can't limit the number 
as each of the services we contract for require passwords and, as 
far as I can tell at least two require specially formatted 
passwords for access to remote systems that they dictate its 
structure must be and, to prevent potential hacking, we can not 
"administratively" replace. But in order to properly audit their 
actions we need to see the data in these external file systems.

The primary reason for using a two password storage file is to 
help prevent one person from accessing another person's files so 
they can do the crookedness as though they were the other person.

In general your approach would be fine if all the systems were 
within our computer systems.

Thanks,

Allen


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190608/cfeb8ff0/attachment.html>