Hi Burak,
and thanks pointing to you work. The memory-pinning was rather easy to
integrate, have a look:
https://github.com/ms140569/loki/commit/ad02ac092e56d4ac96ffaf8b737dac515516abfe
Timing-out the key-agent is something which came to my mind as well - i
guess i'll do it optionally.
cheers
On Tue, Oct 16, 2018 at 1:55 PM Matthias Schmidt
wrote:
>
> And here it is:
>
> https://github.com/ms140569/loki/releases/tag/1.2.0
Thanks for sharing this. I find this interesting because I've been
working on a very similar idea for an OIDC token manager CLI, and came
up with almost the same sc
Thanks for giving it a go!
cheers,
Matthias
Am Dienstag, 16. Oktober 2018 13:32:20 UTC+2 schrieb Thorsten Sommer:
>
> Thank you Matthias, for sharing your work. I find your password manager
> useful. Keep the good work.
>
> Am Sonntag, 14. Oktober 2018 17:49:04 UTC+2 schrieb Matthias Schmidt:
>
And here it is:
https://github.com/ms140569/loki/releases/tag/1.2.0
Thanks to your guy's input the key-agent should be now way more secure.
cheers,
Matthias
Am Dienstag, 16. Oktober 2018 20:31:42 UTC+2 schrieb Matthias Schmidt:
>
> Hi Christopher + Eric,
>
> thanks for your feedback. You are r
Maybe we're talking about different things. Are you thinking of TOTP
2FA tokens? Your arguments do apply to those.
I'm not talking about those. I'm talking about devices like a yubikey,
which is essentially a a poor person's HSM.
On Mon, Oct 15, 2018 at 7:21 PM robert engels wrote:
>
> That is n
Hi Christopher + Eric,
thanks for your feedback. You are right, i really underestimated the risk
of such attacks.
I will lock the key-holding memory in the next release.
cheers,
Matthias
Am Montag, 15. Oktober 2018 23:13:32 UTC+2 schrieb Christopher Nielsen:
>
> On Mon, Oct 15, 2018 at 1:28
Thank you Matthias, for sharing your work. I find your password manager
useful. Keep the good work.
Am Sonntag, 14. Oktober 2018 17:49:04 UTC+2 schrieb Matthias Schmidt:
>
> Hi Gophers,
>
> I’ve created a command line password manager in the style of the “pass”
> utility by Jason A. Donenfeld (h
The attack does not require the attacker to have root on the compromised
machine. It does, however, require the page file not to be encrypted, as is
common on Linux and Unix systems. The attack I've described requires
physical access, e.g. by quickly copying the hard disk. There are special
too
Also, what maybe I wasn’t clear here - that is the ‘verification is local - say
a local app’, if the machine has been compromised - the binary can be edited to
remove the security check - no need to even have the dongle - thus the
requirement for an external resource being protected.
> On Oct 1
That is not true. If you lose the key, anyone else can use the device - which
is why there is usually an additional requirement beyond the hardware key - I
am referring to hardware dongles given to users.
By LOSE I meant unknowingly lost - not that once I lose it and KNOW I’ve lost
it I deactiv
On Mon, Oct 15, 2018 at 4:33 PM robert engels wrote:
>
> To clarify, this is for a hardware device that protects a local resource - a
> network based protocol that challenges the device for access is a different
> story, and yes, when properly implemented is secure (unless someone steals
> your
On Mon, Oct 15, 2018 at 4:25 PM robert engels wrote:
>
> Maybe, but still, if they have root access to your machine, they can just as
> easily alter the accessing binary to send the decoded password elsewhere
> after it has decoded it…
Which is why you disable remote root access on hosts that r
To clarify, this is for a hardware device that protects a local resource - a
network based protocol that challenges the device for access is a different
story, and yes, when properly implemented is secure (unless someone steals your
device! - which is why it is usually password + device, and the
Maybe, but still, if they have root access to your machine, they can just as
easily alter the accessing binary to send the decoded password elsewhere after
it has decoded it…
Which is why applications on osx are “signed” (to prohibit tampering) (although
if you have root access - you could prob
On Mon, Oct 15, 2018 at 3:10 PM robert engels wrote:
>
> Exactly - and systems do not typically have this - yet are considered secure.
> If the plain text is ever available - and it almost always is (in the
> original input component, etc.) it is always subject to attack/hack - and as
> far as
Exactly - and systems do not typically have this - yet are considered secure.
If the plain text is ever available - and it almost always is (in the original
input component, etc.) it is always subject to attack/hack - and as far as I am
aware without hardware support (dongle, etc.) this is a lim
If the user has the ability to read the page file - i.e. root - then he also
has the ability to use the debugger to inspect the live memory as well - so as
the OP pointed out - if root is compromised - nothing is secure.
> On Oct 15, 2018, at 4:36 PM, EricR wrote:
>
> If the memory in which th
On Mon, Oct 15, 2018 at 2:17 PM robert engels wrote:
>
> As long as the passwords are not stored in plain text in memory - meaning
> they are only temporarily decoded in order to be provided (and then the
> memory wiped) - there is no difference than the underlying security of the
> file encryp
If the memory in which the master key resides is not locked, then it may be
written to the page file. An attacker may thus boot the machine from an
external disk, mount the disk, read the page file, obtain the master key
from the page file, and then decrypt the password database. The attack
req
As long as the passwords are not stored in plain text in memory - meaning they
are only temporarily decoded in order to be provided (and then the memory
wiped) - there is no difference than the underlying security of the file
encryption on disk, no ?
> On Oct 15, 2018, at 4:13 PM, Christopher N
On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt
wrote:
>
> Hi Eric,
>
> thanks *a lot* for your valuable feedback! I really appreciate it. See
> comments inline:
>
> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>>
>> Since you're looking for opinions on the security concept, two que
Hi Eric,
thanks *a lot* for your valuable feedback! I really appreciate it. See
comments inline:
Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR:
>
> Since you're looking for opinions on the security concept, two questions
> spring immediately to my mind:
>
> 1. Does the daemon keep th
Since you're looking for opinions on the security concept, two questions
spring immediately to my mind:
1. Does the daemon keep the sensitive data in locked memory that cannot be
paged out? If so, how cross-platform is this?
2. How does the client communicate securely with the daemon? Which
en
23 matches
Mail list logo
