Re: Wireless home LAN - WiFi vs Bluetooth?

[Celejar <celejar@gmail.com>]

On Wed, 31 Jul 2019 16:07:33 +0300
Reco <recoverym4n@enotuniq.net> wrote:

> 	Hi.
> 
> On Wed, Jul 31, 2019 at 07:58:54AM -0400, Celejar wrote:
> > On Wed, 31 Jul 2019 10:43:48 +0300
> > Reco <recoverym4n@enotuniq.net> wrote:
> > 
> > > 	Hi.
> > > 
> > > On Tue, Jul 30, 2019 at 07:06:08PM -0400, Celejar wrote:
> > > > On Mon, 29 Jul 2019 13:57:25 +0300
> > > > Reco <recoverym4n@enotuniq.net> wrote:

...

> > > > > You have authentication frames that can be intercepted (so WPA
> > > > > passphrase can be bruteforced).
> > > > 
> > > > Lots of things (such as TLS, ssh) can theoretically be brute forced -
> > > > the question is whether such brute forcing is sufficiently practical to
> > > > be a threat. I have seen nothing to indicate that properly configured
> > > > WPA2 can be realistically brute forced.
> > > 
> > > For WPA2 it's not that hard really, assuming pre-shared key usage.
> > > Can be expensive (all those videocards and ASICs have their cost), but
> > > definitely doable.
> > 
> > I'd be interested in seeing some real-world studies, or simply just a
> > mathematical analysis of how much hardware would be necessary to crack
> > a good WPA2 password. I've seen lots of sites explaining how to use
> > hashcat with a GPU, and various real-world tests on lists of hashed
> > passwords (e.g., [1]), but can you provide a serious analysis of the
> > practical cost, in time or hardware, of cracking a real-world WPA setup?
> 
> Cost - Amazon will take 11c per hour for that VM that comes with NVIDIA
> Tesla videocard.
> Said hour is more than enough to bruteforce 8 character WPA passphrase
> with hashcat.

Yes, and who said anything about using 8 character passphrase? How
about the cost of cracking a 16 character passphrase? Or a 60 character
one?

> > > You have several encryption algorithms, but:
> > > > > b) You may have a hardware that lack support for a good ones.
> > > > 
> > > > I suppose, but my impression is that most hardware from the last few
> > > > years is fine.
> > > 
> > > Cheap smartphones and tablets. Whatever they put instead of a proper
> > 
> > This misses the point - we're comparing ethernet to wifi. Cheap
> > smartphones and tablets aren't usually going to support ethernet.
> 
> You seem to misunderstand me.
> 
> You have a network that's supposed to be secure.
> You have that small herd of assorted client devices, some of them are
> better, some are worse.
> Excommunicating "bad devices" from the network is usually out of
> question if said devices are owned by family members or trusted friends
> or, say, business associates.

I understand all that, but then your recommendation of "use ethernet"
doesn't solve the problem: how is that "herd of assorted client
devices", which - by your assumption - includes "cheap smartphones and
tablets" that may be owned by family members, trusted friends, or
business associates, going to connect via ethernet?

> Due to the way APs work you cannot announce one set of encryption
> algorithms to one client, and different one to another, hence you bring
> down announced algorithms to the lowest common denominator.
> 
> You can announce several, but it's bad for obvious reasons.
> You *could* get away with it with mutliple virtual APs, but that adds
> complexity.

Well, that is what I do (guest network, network for devices that don't
support 802.11ac), and it does add some complexity, but I wouldn't
call it "fiendishly difficult" - I don't have your network chops, and
I probably wouldn't be able to handle it if it were really that
difficult ;)

Celejar