Christopher Browne wrote:
Why do you think that's useful in limiting vulnerability?
In order for the system to mount the filesystem, the key has got to be
there.
It does not have to be locally on the system. If I wanted to secure
such a system, I would have a private key for decrypting the fil
On 12/6/2004 6:10 PM, Greg Stark wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
Actually, hard disk encryption is useful for one thing: so if somebody
kills the power and takes the hard disk/computer, the data is safe.
While it's running it's vulnerable though...
Where do you plan to kee
Daniel Martini <[EMAIL PROTECTED]> writes:
> Well, where do you plan to keep the key for your encrypted backup tapes,
> like you suggested in another post in this thread ;-)
> That's pretty much the same problem.
No it's not. I can keep the key for the encrypted backup tapes in my pocket. I
won'
Hi,
Citing Greg Stark <[EMAIL PROTECTED]>:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > Actually, hard disk encryption is useful for one thing: so if somebody
> > kills the power and takes the hard disk/computer, the data is safe.
> > While it's running it's vulnerable though...
>
> W
Why do you think that's useful in limiting vulnerability?
In order for the system to mount the filesystem, the key has got to be
there.
If it's a "highly available" system, it's not acceptable for the
system to have to wait for a sysadmin to type in a decryption key, so
the key has to be sitting
The world rejoiced as [EMAIL PROTECTED] (Martijn van Oosterhout) wrote:
> On Mon, Dec 06, 2004 at 04:07:25PM -0500, Greg Stark wrote:
>> By contrast, encryption is useful for non-live data such as
>> database backups. This lets you take them off-site and store them
>> someplace without worrying ab
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Actually, hard disk encryption is useful for one thing: so if somebody
> kills the power and takes the hard disk/computer, the data is safe.
> While it's running it's vulnerable though...
Where do you plan to keep the key?
--
greg
-
On Mon, Dec 06, 2004 at 04:07:25PM -0500, Greg Stark wrote:
> By contrast, encryption is useful for non-live data such as database backups.
> This lets you take them off-site and store them someplace without worrying
> about someone walking off with your entire database. Or to discard the tapes
> w
Derek Fountain <[EMAIL PROTECTED]> writes:
> On Monday 06 December 2004 12:31, you wrote:
> > Derek Fountain <[EMAIL PROTECTED]> writes:
> > > If another SQL Injection vulnerability turns up (which it might, given
> > > the state of the website code),
> >
> > You will never see another SQL injecti
On 12/6/2004 1:33 AM, Derek Fountain wrote:
On Monday 06 December 2004 12:31, you wrote:
Derek Fountain <[EMAIL PROTECTED]> writes:
> If another SQL Injection vulnerability turns up (which it might, given
> the state of the website code),
You will never see another SQL injection vulnerability if yo
Hi,
Citing Derek Fountain <[EMAIL PROTECTED]>:
> Indeed, but I'm still interested in the general answer.
There is no general answer. Depends on how deep you get into trouble, if
the data is compromised.
> The server I have been looking at was hopelessly insecure and SQL
> injection is only one o
Greg Stark wrote:
Derek Fountain <[EMAIL PROTECTED]> writes:
If another SQL Injection vulnerability turns up (which it might,
given the state of the website code),
You will never see another SQL injection vulnerability if
Never say never..
--
Until later, Geoffrey
---(end
On Sun, Dec 05, 2004 at 11:31:34PM -0500, Greg Stark wrote:
> Derek Fountain <[EMAIL PROTECTED]> writes:
> > If another SQL Injection vulnerability turns up (which it might, given the
> > state of the website code),
>
> You will never see another SQL injection vulnerability if you simply switch
From: "Derek Fountain" <[EMAIL PROTECTED]>
> [snip discussion about encrypting data]
> Indeed, but I'm still interested in the general answer. The server I have
been
> looking at was hopelessly insecure and SQL injection is only one of its
> problems. There were several other ways in! Assume, for
On Monday 06 December 2004 12:31, you wrote:
> Derek Fountain <[EMAIL PROTECTED]> writes:
> > If another SQL Injection vulnerability turns up (which it might, given
> > the state of the website code),
>
> You will never see another SQL injection vulnerability if you simply switch
> to always using
In the last exciting episode, [EMAIL PROTECTED] (Derek Fountain) wrote:
> It seems silly to tell him to encrypt everything, including customer
> names and addresses, etc. - I've never heard of DB admin
> recommending such action - and it'll have an impact on
> performance. So where do I draw the li
Derek Fountain <[EMAIL PROTECTED]> writes:
> If another SQL Injection vulnerability turns up (which it might, given the
> state of the website code),
You will never see another SQL injection vulnerability if you simply switch to
always using prepared queries and placeholders. Make it a rule tha
A customer of mine recently asked me to try a penetration test on his website,
and I found a nice SQL Injection vulnerability. Using that vuln I was able to
wander round his DB at will, viewing customer information, user logins,
passwords, the lot. He asked me to make some recommendations, of wh
18 matches
Mail list logo
