On 18/10/2013 16:05, Tanstaafl wrote:
> On 2013-10-18 7:19 AM, Alan McKinnon wrote:
>> On 18/10/2013 12:23, Tanstaafl wrote:
>>> On 2013-10-17 10:30 PM, Walter Dnes wrote:
I apologize. That is arguably a two factor system. When you said
"ssh key and password", I "jumped to delusions",
On 2013-10-18 7:19 AM, Alan McKinnon wrote:
On 18/10/2013 12:23, Tanstaafl wrote:
On 2013-10-17 10:30 PM, Walter Dnes wrote:
I apologize. That is arguably a two factor system. When you said
"ssh key and password", I "jumped to delusions", assuming that it was a
standard ssh connection with
On 18/10/2013 12:23, Tanstaafl wrote:
> On 2013-10-17 10:30 PM, Walter Dnes wrote:
>> I apologize. That is arguably a two factor system. When you said
>> "ssh key and password", I "jumped to delusions", assuming that it was a
>> standard ssh connection with the option of either key or password.
On 2013-10-17 10:30 PM, Walter Dnes wrote:
I apologize. That is arguably a two factor system. When you said
"ssh key and password", I "jumped to delusions", assuming that it was a
standard ssh connection with the option of either key or password.
Side question...
So, wouldn't the simplest t
On 18/10/2013 04:30, Walter Dnes wrote:
> On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote
>
>> Accessing the actual backend network is a two stage process: ssh key to
>> the jump host, then password to get onto the actual destination.
>>
>> So it's "two factor" as a generic English l
On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote
> Accessing the actual backend network is a two stage process: ssh key to
> the jump host, then password to get onto the actual destination.
>
> So it's "two factor" as a generic English language phrase, not "two
> factor" as a technic
On 17/10/2013 01:21, Walter Dnes wrote:
> On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote
>
>> Access to my backend network is two-factor - ssh keys and decent
>> passwords.
>
> That is *NOT* Two-factor authentication. See
> http://en.wikipedia.org/wiki/Multi-factor_authenticatio
On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote
> Access to my backend network is two-factor - ssh keys and decent
> passwords.
That is *NOT* Two-factor authentication. See
http://en.wikipedia.org/wiki/Multi-factor_authentication for the
details. Executive summary... Two-factor
On 10/14/2013 04:31 PM, Alan McKinnon wrote:
>
> Keep in mind the actual original purpose of a salted hash.
>
> If two users happen to use the same password[1], the hashes are the same
> and this is revealed to anyone who can read /etc/passwd[2] i.e everyone.
Ah, the single-entry rainbow table =
On 14/10/2013 20:23, Tanstaafl wrote:
> On 2013-10-13 4:07 PM, Martin Vaeth
> wrote:
>> Like passwords, these sequences should better not stay the same for
>> too long...
>
> Forced changing of passwords (and I imagine the same can be said for
> port-knocking sequences, which I've never implement
On 14/10/2013 21:17, Michael Orlitzky wrote:
> On 10/14/2013 02:49 PM, Martin Vaeth wrote:
>>
>>> Hiding the salt would just be security through obscurity.
>>
>> And yet it is stupid if you do not do it and give away a
>> huge constant factor for no advantage.
>>
>
> (I'll just agree to disagree a
On 2013-10-14 2:52 PM, Martin Vaeth
wrote:
Tanstaafl wrote:
Like passwords, these sequences should better not stay the same for
too long...
Forced changing of passwords
I agreee: To do this to protect *other* users will not work.
It's a different thing if you use it for protection of your
On 10/14/2013 02:49 PM, Martin Vaeth wrote:
>
>> Hiding the salt would just be security through obscurity.
>
> And yet it is stupid if you do not do it and give away a
> huge constant factor for no advantage.
>
(I'll just agree to disagree about the rest.)
Keeping the salt secret makes your ap
Tanstaafl wrote:
>> Like passwords, these sequences should better not stay the same for
>> too long...
>
> Forced changing of passwords
I agreee: To do this to protect *other* users will not work.
It's a different thing if you use it for protection of your own data...
Michael Orlitzky wrote:
> On 10/14/2013 07:49 AM, Martin Vaeth wrote:
>>
>> Using yet another service with possible holes to protect a sshd?
>> In this case, I would like port knocking at least for this OpenVPN.
>
> The sensitive parts of OpenVPN are audited regularly, and it uses "SSL"
> -- publi
On 2013-10-13 4:07 PM, Martin Vaeth
wrote:
Like passwords, these sequences should better not stay the same for
too long...
Forced changing of passwords (and I imagine the same can be said for
port-knocking sequences, which I've never implemented, but am intrigued
by, although I tend to avoid
On 10/14/2013 07:49 AM, Martin Vaeth wrote:
> Michael Orlitzky wrote:
>> Port knocking is cute, but imparts no extra security.
>
> It does, for instance if you use it to protect sshd and
> sshd turns out to be vulnerable; remember e.g. the
> security disaster with Debian.
>
>> A better, secure w
On 14/10/13 20:08, Martin Vaeth wrote:
> William Kenworthy wrote:
>>
>> If you are going to go to this bother ... why not use shorewall, create
>
> When I checked for scripts creating rules, none fulfilled my needs.
> (I do not know whether I checked shorewall at this time).
> For instance, inste
William Kenworthy wrote:
>
> If you are going to go to this bother ... why not use shorewall, create
When I checked for scripts creating rules, none fulfilled my needs.
(I do not know whether I checked shorewall at this time).
For instance, instead of dropping most packets, I want to reject them
Pandu Poluan wrote:
>
> Thanks, Martin! I was about to create my own preprocessor, but I'll check
> out yours first. If it's what I had planned, may I contribute, too?
Sure, patches are welcome.
Michael Orlitzky wrote:
> Port knocking is cute, but imparts no extra security.
It does, for instance if you use it to protect sshd and
sshd turns out to be vulnerable; remember e.g. the
security disaster with Debian.
> A better, secure way to achieve the same goal is with OpenVPN.
Using yet an
On 10/13/2013 04:07 PM, Martin Vaeth wrote:
>>
>> I was just reiterating that there's not much benefit to save/restore if
>> you're doing things properly (pontification alert!).
>
> For a laptop of a scientist like me this is not true at all - it must
> often be connected in a different environmen
On 14/10/13 04:07, Martin Vaeth wrote:
> Michael Orlitzky wrote:
[...]
If you have a million rules and you need to wipe/reload them all
frequently you're probably doing something wrong to begin with.
>>>
>>> I don't know how this is related with the discussion.
>>> The main advantag
Michael Orlitzky wrote:
>>> [...]
>>> If you have a million rules and you need to wipe/reload them all
>>> frequently you're probably doing something wrong to begin with.
>>
>> I don't know how this is related with the discussion.
>> The main advantage of using iptables-restore is avoidance of
>>
On 10/13/2013 11:19 AM, Martin Vaeth wrote:
>>>
>> [...]
>> If you have a million rules and you need to wipe/reload them all
>> frequently you're probably doing something wrong to begin with.
>
> I don't know how this is related with the discussion.
> The main advantage of using iptables-restore i
Michael Orlitzky wrote:
> On 10/13/2013 06:08 AM, Martin Vaeth wrote:
5. You can't script iptables-restore!
>>>
>>> Well, actually you can script iptables-restore.
>>
>> For those who are interested:
>> net-firewall/firewall-mv from the mv overlay
>> (available over layman) now provides a sep
26 matches
Mail list logo
