News for hackers. Stuff that matters.

aris_ada

Re:SSH: Best practices on Monday February 08, 2016 @09:25AM (#11058216)
I facepalmed so hard my forehead hurts
Re:SSH: Best practices on Monday February 08, 2016 @03:02AM (#11056885)
I wrote the article.
Re:SSH: Best practices on Sunday February 07, 2016 @04:30PM (#11054951)
I didn't know that tool. Having different agents for different projects may be useful, especially if you're using Agent Forwarding.

I don't like that you have to alias ssh or replace /usr/xxx/bin/ssh with a symlink to make it work.

Re:SSH: Best practices on Sunday February 07, 2016 @04:26PM (#11054931)
Compliance has very little to do with actual security unfortunately...
Re:SSH: Best practices on Sunday February 07, 2016 @04:22PM (#11054915)
Have each team member generate his own key. Copy everyone's key in a folder and have a script to generate an authorized_keys file. Use puppet or chef (or anything else) to dispatch the authorized_keys on every server.

A single shared key is a security disaster waiting to happen.

Re:SSH: Best practices on Sunday February 07, 2016 @04:19PM (#11054902)
Unfortunately biometrics are near to useless for remote authentication. The only context in which biometrics work is when the whole authentication chain (reader, cable, computer, network) is tamper-proof. When one of these elements can be tampered with (e.g. unplugging the fingerprint reader and sniffing to the USB traffic), it becomes "something you know, that anyone can collect, that you can reproduce with an HD picture, and that you cannot revoke without losing your physical integrity".

I think biometrics may have a place in tamper-proof devices like iphones (infamous error 53) or biometric smartcards (need fingerprint to unlock secrets).

Re:SSH: Best practices on Sunday February 07, 2016 @03:39PM (#11054694)
I just noticed this an hour ago. Bad config on the server and too little ram. The link should work better now.
Re:The war against autocomplete=off (2013) on Friday March 14, 2014 @04:44PM (#7401727)
I did not test LastPass and 1Password, only FF sync & Keepass. And it was a while ago.
Re:The war against autocomplete=off (2013) on Friday March 14, 2014 @04:42PM (#7401711)
Sorry, I don't have time to do so much work just to log on quickly on my email the morning or when relogging for the 25th time in the ticket manager at work, that has too short sessions. Also, enjoy explaining your method to a lambda user, I'd bring popcorn and watch :)
Re:The war against autocomplete=off (2013) on Friday March 14, 2014 @04:38PM (#7401672)
Seriously, blocking copy & paste, what are they thinking they protect from ?

(blogpost writer here)

Re:Dual_EC_DRBG backdoor: a proof of concept on Wednesday January 01, 2014 @01:45PM (#6995938)
No, they plan on removing the PRNG from their release. I understand better why my POC worked without triggering the bug. From the mail archive: ". When the discard occurs the data must not be output and the Dual EC DRBG state must be updated, but that state update isn't done. In the case of no additional input this has no effect, but additional input is used by the "FIPS capable" OpenSSL. Note that additional input does not effectively defeat the backdoor vulnerability[3]."

I do not use the reseed functionality either, because I only generate two or three output blocs and never call an explicit reseed.

Re:Dual_EC_DRBG backdoor: a proof of concept on Wednesday January 01, 2014 @12:43PM (#6995632)
Honestly I don't know why. I generate 60 bytes of pseudorandom and that worked on first try.
Re:Dual_EC_DRBG backdoor: a proof of concept on Wednesday January 01, 2014 @12:42PM (#6995624)
Fixed. Sorry, French is my first language and I do my best in English, but I learn every day :)