Re: Security Diligence

Hi, On 8 February 2014 13:04, Lester Caine <lester@lsces.co.uk> wrote: > Hopefully to put some of the discussions into context of where they fit in > the real world. Is the 'timing attack' or problems created by an 'insecure' > random number a practical proposition? The only physical proof that I have http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html I wrote that as detailed as I could for a general audience. The weaknesses of various PRNGs has been exhaustively studied. > seen presented for the 'timing attack' is 10 years old and relates to a My blog references research from 2010 and I've referenced blog article and two live talks from around the same year in an earlier email to you. You keep insisting on having physical proof in a realm of study where the research must be carried out both legally and ethically, and actual exploits are rarely disclosed by the criminals who use them. The exploit was proven to be practical which means it has surpassed the bar where it needs to be actively defended against. There was no physical proof that you could hack a refrigerator in 2013 but we've already had a long history of warning people about default passwords and poor configuration of home devices. Under your logic, that would mean we have no need to audit and secure refridgerators. There was no physical proof that an attack had ever occured. Of course, that line of thinking looks remarkably poor when someone actually does hack a refridgerator, because all those security people were right afterall. This really happened - it got detected (not publicised by the hacker!) by a research team: http://www.businessinsider.com/hackers-use-a-refridgerator-to-attack-businesses-2014-1 > 'small local network'? Processor speed has increased a little in 10 years > and we now tend to work in 64bit chunks rather than 8 or 16bit? Although > that does also enhance the power of the hackers ... So discussing something > based on timing 8bit characters seems a little strange? Firebird code > dropped the 10 year old process a few versions back. I was trying to > establish where the risk was in PHP and while I am more than happy it does > not exist in my own applications, while it remains an 'unpatched security > risk' others will not accept that fact. What is still missing from the > discussion is the level of risk these 'security problems' present? Grounding That's a loaded gun because nobody here has audited your application so I can't assess the risk of any given vulnerability for your specific context. If I assume a worst case scenario, e.g. passwords hashed using MD5, then a timing attack might well be high risk since reversing the hash is so simple. If you use bcrypt, the risk would be lower but you'd still need to go ask users to change their passwords and suffer the negative publicity that may prompt. If you create CSRF tokens using mt_rand(), again the risk would be higher compared to using a strong random source - read the book chapter. Of course how are you interpreting risk? Is it the possibility of an attack occuring, or the possibility of an attack being successful? The general principle is that the former is a given. As I implied before, a lot of people didn't take MITM attacks as seriously as they should have until Edward Snowden came along. That erroneous sense of priorities is something we should try not to fall victim to. You need to get out of the box where security is your enemy. It's an evolving animal and PHP 5.6 is evolving to meet that challenge. Your auditor is perfectly entitled and correct to raise questions over PHP 5.2. He's correct to raise concerns over timing attacks. He's doing his job. If he didn't raise and press those concerns, I'd fire him in favour of someone more competent. >Why is this all so futile? >The system is still using the same 4 digit 'pin number' to identify a staff id that >was instigated >when the system was first designed back in 1992, and when many access positions were just >numeric pads with small displays! >No sensitive data is stored ... Unless you own the data, you don't get to say it's not sensitive. It's not your data. Is your place of work in the habit of releasing Staff IDs to the public so I can ring some poor ignorant soul at a service desk and beg them to reset my passwords inside your network? Is it in the habit of disclosing on a public forum that it runs vulnerable software that protects Staff IDs so that I can find that in a Google search and start winding up my social engineering cannon and penetration skills? Your consultant is trying to bolster security and this is unlikely to be the first time they've met resistance to their recommendations. It's actually quite a common part of the job, and it's also why consultants get called in in the first place - to be independent of your concerns and those of the IT dept so that they can offer an objective expert opinion. In their view, you are the refrigerator. I can be a harsh judge, but don't take this the wrong way. You need to put a little trust in the expertise of others and not put it all on you. When security researchers are running scared over an issue, they usually don't do so without some compelling motivation. By all means, do your own research, but you need to also develop a sense of risk and a skill in gauging the implications of any given threat. You see PHP 5.2 as being acceptable. I see it as a frickin' bomb waiting to go off. Yet, we both agree that it's not secure? That our risk assessment differs significantly is probably putting it mildly ;). -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative