Comments for Stack Exchange Security Blog The Security Stack Exchange Blog Sat, 06 Feb 2016 05:11:22 +0000 hourly 1 Comment on QoTW #53 How can I punish a hacker? by Jon Sat, 06 Feb 2016 05:11:22 +0000 LOIC the IP? What should you do? Best case: Ban the IP

]]> Comment on QoTW #53 How can I punish a hacker? by Insane Sat, 06 Feb 2016 02:07:22 +0000 In this case, they did some free penetration testing!

]]> Comment on QoTW #53 How can I punish a hacker? by Alexey Vesnin Fri, 05 Feb 2016 22:02:37 +0000 Very good point!

]]> Comment on QoTW #53 How can I punish a hacker? by silverpenguin Fri, 05 Feb 2016 16:29:13 +0000 you dont punish them you find them and thank them. nothing was damaged other than your ego. you just got work done for free, your security is now better from people who actually want to break your things rather than just want to test them selves.

]]> Comment on Debunking SQRL by Ian Thu, 02 Jul 2015 06:27:19 +0000 There was a lot of garbage written in this piece as well as in the comments. 1. SQRL does not represent a single point of failure. You could generate a different private key for each site if you wished to. The single master password model is just a suggested way to use SQRL.

  1. SQRL is far less vulnerable to social engineering than a password. If a password can be remembered by its user then it can be coerced out of them. No one can remember an SQRL private key. Passwords can be captured by keyloggers, SQRL keys cannot.

  2. The one point about SQRL no one mentioned and the reason it is far more secure than a password, the SQRL private key is never sent anywhere. The server encrypts a random string with the SQRL public key. This can only be decrypted with the SQRL private key on the users computer. The decrypted string is then sent to the server to prove the user is the owner of the private key.

  3. SQRL is not “new untested technology” The SQRL protocol just uses existing public/private key technology in a better, more secure way than it is currently used.

Comment on A Brief Introduction to auditd by Dwight Spencer Sun, 07 Jun 2015 20:09:07 +0000 A central logging system is going to fit this use case. Logstash, Logentries and Splunk all give a great user experence and have powerful quering languages.

However, I would incurrage one to use logstash/elasticsearch since the free version of splunk and logentries do have several caviates when going over data storage or bandwidth restrictions.

Also, one can utilize fluentd and collectd+statsd+graphana with logstash and get a better picture of what is going on with ones environment footprint. With fluentd one can even create actionable agents based on the alerts to preform basic procedual administrative tasks via abutraial execuables. (ie, kill long running tasks, null route ddos, launch additional running virtual instances in ones cloud)

Comment on A Brief Introduction to auditd by tdurden Wed, 03 Jun 2015 16:49:38 +0000 splunk is $$, try greylog2..

]]> Comment on QotW #1: How does changing your password every 90 days increase security? by Havenless Fri, 24 Apr 2015 07:35:59 +0000 If you’re compromised, important people will want to know why you didn’t follow “industry standard practice”.

It’s industry standard practice because everyone follows it.

Everyone follows it because it’s industry standard practice.

Comment on Base Rulesets in IPTables by vinzBad Thu, 16 Apr 2015 14:16:21 +0000 Is there a reason, why you append these rules to INPUT and not PREROUTING?

]]> Comment on Confidentiality, Integrity, Availability: The three components of the CIA Triad by Ahmad Bashir Sun, 12 Apr 2015 23:02:52 +0000 Have the information security management have any conclusion on security management yet in the way that with C I A in other way have risk management put into control.