Re: Security Diligence

On Sat, Feb 8, 2014 at 12:52 PM, Lester Caine <lester@lsces.co.uk> wrote: > I think an explanation of my recent posts is probably due. > > The bulk of my income is from council and other local authority customers > who are required to jump through many often difficult to identify hoops. > They are currently being put through another round of 'security > assessments' and I had a second visit to a site which we have yet to > upgrade from PHP5.2 earlier this week. The system is doing exactly what the > 'customer' wants ( the client is the customer services team ), and while > the IT department has been providing network access since it was installed > in 2007, it has no outside access other that a VPN/VNC link so I can carry > out maintenance. As a result it has not been necessary or easy to upgraded > to later 'security patches'. > > It's the last of my 'CMS' sites that I have to upgrade to PHP5.4 and that > was the discussion before Xmas, but the IT department have now realised > that they should be managing the network better :) Driven by their current > security assessment, linked to removing Windows XP from it. Since two of > the CMS machines are running XP, these will need to be replaced, but it is > the Apache/PHP stack which the 'security consultant' has been targeting > insisting that only a CURRENT version of both will be acceptable, and > PHP5.4 is not current in his eyes despite it getting security updates > independent of PHP5.5. > > I am more than happy that within the constraints applied I have maintained > the PHP5.2 setup as 'safe' as I can and since these sites are all ring > fenced inside the site network personally I do not see a problem. This view > is actually supported by the IT staff, it is the independent consultant who > is now putting up objections to our continuing to supply the CMS service. > Unpatched reported security problems are one of his objections and timed > attack was one brought up probably because it's discussion is currently > happening! We are currently trying to work out how to move forward, and > since the service provides an essential part of the handling of visitors > there is a desire by the users to maintain it ;) > > 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 ... > > ( Firebird's password is still limited to 8 characters for historic > reasons, so the length is a known and the hash decode is designed to check > all characters even if an earlier compare fails ... so maintains a fixed > test time ) > I'm sorry, but how does this relate to the internals mailing list? Thanks, Nikita