Security is ultimately all about making it cost too much (of at least
time, money, effort, requirements, social factors) to break in. Even
so-called 'real' security vs. security in depth and security by
obscurity is really on the same spectrum.
That is why those who make bald statements about there being no point to
security that isn't what they deem 'real' security, miss the reality
that they're just talking about different points on the same spectrum.
Not that one should rely on *soley* on security by obscurity, but the
reality is that even security by obscurity has it uses and can at least
reduce attack surface.
For that matter the much vaunted example of DVD encryption shows that as
much as weak security can be broken, it can achieve the ultimate
objective well enough for long enough. (In this case the objective is
big media profits; dvd encryption prevented ordinary people from
circumventing for long enough for them to make profit, therefore it
actually succeeded at what it was designed for).
People tend to assume the objective of security is always absolute 'keep
everyone out, even extremely well-funded antagonists', but that is not
always actually the case.
Most of the time, the objectives are much more modest, and expecting
people to prevent physical access to their home router or other devices
running openwrt is rather unrealistic, but that doesn't mean we should
leave it as trivial for someone to walk up to the device and gain
passwordless root access.
It's all about managing the real risk of real situation using means that
are not too onerous for benefit gained.
Like much of life, security is not nearly as black and white as many
like to paint it (same with 'green' energy vs. fossil fuels; there is
truly 'green' energy except not using energy, there are only degrees,
and one needs to assess the full set impacts to really make an good
decision about what's the right course of action).
Regards,
Daniel
On 24/12/15 04:51 PM, Sami Olmari wrote:
-1 to default key...
> at the moment the user *is* used to a key mismatch, because
every box comes up with 192.168.1.1 and another key.
No need to generate another weak point just because there can be another
similar one...
More general, should a bad guy have physical access to an device, be it
embedded router or full server, the game is mostly lost at that point
already... He can allways take out the hard disk and boot own linux and
read the contents etc...
I could see the point of serial connection asking password in normal
boot, but no point with that in failsafe... for same reasons than
above... mr bad guy can even flash own bootloader to do stuff should he
need access to embedded device contents...
So, to recap, bad guy + physical access = game over, no matter what you
try to do...
mine .02, Sami Olmari
On Thu, Dec 24, 2015 at 11:33 PM, Bastian Bittorf
<[email protected] <mailto:[email protected]>> wrote:
* Michael Richardson <[email protected] <mailto:[email protected]>>
[24.12.2015 22:14]:
> >> > till the real keys are generated? it can last several minutes on
some
> >> > routers and it feels like the box is broken. also: if really
something
> >> > goes wrong during key generating we can at least login.
> >>
> >> you have a very bizarre understanding of securing a device.
>
> > in this stage the box is still without password.
>
> okay. So the impersonator machine lets the user in without a password,
and
> the impersonator machine has ALREADY connected to the new machine with no
> password, and trojan'ed some binaries.
yes, if somebody wants to upload some binaries it's possible.
> > the only issue i can think of is, that one can
> > read on the wire to which password somebody changes
> > with 'passwd' - but i'am pretty sure this is not
> > the case, because each session has it's own privacy.
>
> No, since the impersonator (MITM) has involved itself with the session.
> Effectively, the MITM creates:
>
> ssh mitm 'tee /badguy | ssh target'
>
> (but, bidirectionally, and inside the SSH transport layer)
>
> A new ICMP port-unreachable code would be nice to have here.
interesting idea, but this is also possible with the current
approach. the user has to accept a new unknown key and has no
idea from which box it comes from.
but really, this is really hypothetical - normally you have
1 box on your desk and you are connected via wire to it. what
is your usecase?
bye, bastian
_______________________________________________
openwrt-devel mailing list
[email protected] <mailto:[email protected]>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
