I'm developing on my laptop which is constantly connected to the Internet while I'm working. I installed Apache2 with Ubuntu default settings, MySQL and PHP. How safe is it for me to develop when I'm connected to the Internet? Couldn't sb get access to my system somehow?
@ThomasPornin For systems on which "root" has a real password, a likely attack would be to make a rainbow table for the root salt so it could be reused
@nealmcb Yes -- and similarly, some Unix usernames are very common (e.g. "bob"). But @Ninefingers was talking about hashing full name, address and birthday together, which should be quite discriminating
Thus making the production of a rainbow table not very worthwhile
But rainbow tables are just a very thorough way of parallelizing attacks
A rainbow table on a function f successfully attacks every f(x) where x was considered during table construction -- and no other.
The cost of building the rainbow table is roughly the cost of computing all those f(x)
(multiplied by something like 1.7 because of chain collisions)
If the attacker has all the hashed passwords he wants to attack as one batch, then it is simpler to just hash his dictionary
The attacker will want to store some data (i.e. build a precomputed table) only if he does not have all the hashed password to attack at that point, but foresees that he will get more of them later on.
So building a rainbow table is "worth the effort" (and the disk space) as soon as it is highly plausible that at least one other password will be attacked at a later date.
@ThomasPornin Especially as disk space is cheap and a wide range of Rainbow tables exist online available for free (or by earning entry through participating)
@ThomasPornin Thanks! Probably worth an actual question... But since disk isn't free, the trade-off should include a parameter for disk cost and compute cost
@Ninefingers by the way - why even consider a non-random salt, based on the params you mentioned?
So, I'm getting ready to watch a Sourcefire webinar.
To join the Webinar, please use one of the following supported operating systems: • Windows® 7, Vista, XP or 2003 Server • Mac OS® X 10.4.11 (Tiger®) or newer
@nealmcb Some code I was looking at does it this way and I couldn't think of any reason that was more/less secure than a pile of bytes from /dev/urandom - now I have one. Especially the case for the root user. It is awkward in that changing any of those parameters invalidates the salt anyway, so you then need to re-generate the password, so I intend to replace it.
And in this case it isn't for unix passwords, but it is conceivable a user could be named admin, which is the same problem...
@ScottPack Say I have vulnerability A that is present in Apache Tomcat version B. The vulnerability is fixed in version B.1, but this instance of Tomcat is on a vendor-managed appliance - so, we can't just update it ourselves. The vendor says the vulnerability is also patched by applying a hotfix number X. However, the hotfix doesn't fully update the Apache version, and therefore the vulnerability scanner still flags vulnerability A on the system.
Where would I go to look up the hotfix and independently verify the vendor's claims? Google's been of little to no help.
@ScottPack No, but it does provide a "System Response" - which pretty much indicates to me that it's just checking the version number and not verifying hotfixes.
What I need is a place to look up the hotfix and see that the given hotfix ID: 1.) Actually exists, and 2.) Does address the vulnerability, according to release notes.
Everywhere I've looked so far just says "version B.1 fixes this".
This is a pretty common thing in vendor based Linuxes as well. RedHat, for example, doesn't like updating versions of software for support purposes. So they backport security fixes. Thus, the version numbers can be pretty misleading.
So, really, your best options for verification of patching is to either accept their word that the given vulnerability doesn't exist in a given version of their distribution of Apache, or attempt to exploit it.
I mean, like Microsoft releases patches every month... Example would be how my computer will probably report "Microsoft Windows Version 5.1" until it gets a full OS upgrade. However, application of update KB250827 means that my computer is more secure than an out-of-the box fresh install of XP SP3.
On a related note, the GPL and LGPL tend not to apply well on Java code, there again because the (L)GPL was designed for the C model of compilation and linkage.
Without a specific scenario and threat model in mind it is hard to answer your question.
But one clear win is the classic OAuth use case. It turns out users are amazingly willing to give one web site their password for another web site, e.g. their Google password to a social networking site lik...
I'm surprised we haven't had an S&A close discussion for this one yet
I'm developing on my laptop which is constantly connected to the Internet while I'm working. I installed Apache2 with Ubuntu default settings, MySQL and PHP. How safe is it for me to develop when I'm connected to the Internet? Couldn't sb get access to my system somehow?
Without a specific scenario and threat model in mind it is hard to answer your question.
But one clear win is the classic OAuth use case. It turns out users are amazingly willing to give one web site their password for another web site, e.g. their Google password to a social networking site lik...
