Comments for Stack Exchange Security Blog

Comment on QoTW #53 How can I punish a hacker? by Jon

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

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

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

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

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.

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.
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.
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

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

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

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

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

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.