meta user
network profile
| bio | website | stoneyforest.net |
|---|---|---|
| location | Grand Rapids, MI | |
| age | 31 | |
| visits | member for | 2 years, 5 months |
| seen | May 16 at 4:05 | |
| stats | profile views | 9 |
I'm just a simple IT guy, who does a bit of programming on the side.
|
Oct 17 |
comment |
Is it a bad idea for a firewall to block ICMP? It's one of those "Unless you're a networking god and really know what you're doing, don't mess with it" sort of things. |
|
Oct 3 |
comment |
Alternatives/mitigation to Oracle Java (JRE) Shopping Questions are Off-Topic on any of the Stack Exchange sites. See Q&A is hard, lets go Shopping and the FAQ for more details. |
|
Aug 31 |
comment |
Dealing with excessive “Carding” attempts I'd really discourage the "authentication mechanism" idea, it's 2012, way past the time when "site accounts" should have been dumped outright. CAPTACHA is an excellent idea, as is locking out users who fail it multiple times for a reasonable period of time. |
|
Jul 29 |
comment |
When changing a password, does it have to be completely different? @curiousguy salted MD5 hashes can be cracked within an hour with the right computer (and it's not a supercomputer). It's trivial to find a collision these days because the computational power of computers has simply increased that much. SHA1 is better, by several orders of magnitude; though most cryptographers agree SHA1 is soft-broken as a collision can be found in 2^51 operations (~130 compute-days with a modern OpenCL card). Some MD5 rainbow tables are awfully complete, your password having "entropy" doesn't mean it doesn't collide with a simpler password either. |
|
Jul 25 |
comment |
When changing a password, does it have to be completely different? The "problem" with this answer is that it assumes that only the well hashed password would ever be leaked. If that's the case, then yes this answer is correct. Leaks from Yahoo and others however have shown that well hashed passwords are much too rare. Also, if they're using a poor hash, like MD5, then it's easily reversed via Rainbow Table. Salt is a critical deterrent to rainbow tables, but that's getting into more depth than is necessary for the Answer. TLDR: Your answer relies on too many assumptions to be considered correct security advice. |
|
Jun 13 |
comment |
SIEM-AlienVault; Risk Metrics, Assets, and basics @bubbl35 I don't have any myself, it just wasn't evident from your Question that you had in fact read any. My apologies for asking the obvious. This is a security site regardless, and application configuration questions are off-topic here. Our sister sites Server Fault handles network administration and Super User for application configuration may be of interest; but you'll definitely want to contact the vendor first as (forgive the simplification) "where do I start" questions are generally going to be off-topic on all our sites. |
|
Jun 13 |
comment |
SIEM-AlienVault; Risk Metrics, Assets, and basics Have you tried reading the friendly manual? |
|
Apr 12 |
comment |
Security considerations in providing VPN access to non-company issued computers This is the exact same policy we have. If it doesn't belong to us, it doesn't connect, except Terminal Services (and even that is locked down tight). |
|
Dec 27 |
comment |
Two SSIDs on same Access point- not good? If you have to ask, you probably want to hire someone who really knows their stuff to setup your stuff. It's somewhat easy to muck up if you've never dealt with vLAN specific SSIDs and such before. But yes it's possible and common as Rory says. |
|
Dec 19 |
comment |
Policy requirements of Sarbanes-Oxley (SOX) +1 Possibly related: HIPPA suffers from the same fear, uncertainty, and doubt; because the law is vaguely written at best and most people do not actually know the law very well (or at all). |
|
Dec 4 |
comment |
What are the pros and cons of site wide SSL (https)? @Steve +1, SSL guarantee Encryption. Typically encryption is negotiated, but technically it's not required; an SSL session can be negotiated with authentication only. |
