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 then you are back to the same problem of compromising passwords when root access has been compromised).
> On Oct 15, 2018, at 6:25 PM, robert engels <reng...@ix.netcom.com> 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 applications on osx are “signed” (to prohibit tampering) > (although if you have root access - you could probably also add the bogus > singing cert to the certificate store). As far as I know Linux and its > variants don’t enforced signed binaries. > > I only point this out because you give the impression that because you “use a > hardware device” it is secure - this is not really the case. > > Security is always a trade-off. > >> On Oct 15, 2018, at 6:04 PM, Christopher Nielsen <m4dh4t...@gmail.com> wrote: >> >> On Mon, Oct 15, 2018 at 3:10 PM robert engels <reng...@ix.netcom.com> 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 I am aware without hardware support (dongle, etc.) this is a >>> limitation of all security implementations. >> >> Considered secure by whom? Maybe "secure enough" by most. At the end >> of the day, you have to look at your threat model, attack surface, >> potential attackers, and value of what you want to protect. A password >> manager is a high-value target for obvious reasons. It should have a >> well-defined and vetted security model. Personally, I use a hardware >> security token to secure mine because I don't trust software. >> >>> You don’t always need the plain text though, you can store the one way hash >>> (as in Http Digest security), and use that, so if the store is compromised >>> the users known passwords are not discovered - but it doesn’t mean access >>> won’t be granted. >> >> Sure. It depends what you're doing, of course. >> >>> As far as I know - even ‘keychain access’ in osx (used in millions of >>> systems) would be subject to similar hack to if root was available and >>> memory could be scanned. >> >> It does not follow that because something is used by millions that it >> is secure. Again, maybe "secure enough" for most. I also use a >> hardware token with keychain. >> >> We seem to have wandered pretty far afield of the topic of this forum. >> >> -- >> Christopher Nielsen >> "They who can give up essential liberty for temporary safety, deserve >> neither liberty nor safety." --Benjamin Franklin >> "The tree of liberty must be refreshed from time to time with the >> blood of patriots & tyrants." --Thomas Jefferson >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
