Re: Wireless home LAN - WiFi vs Bluetooth?
On Wed, Jul 31, 2019 at 10:30:05PM -0400, Celejar 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?
Each extra character in WPA passphrase adds roughly two orders of
magnitude to the bruteforce time.
So you cheat. Dictionary attacks, Markov chain attacks, assumptions on
the characters used in passwords - all that really lowers bruteforce
time.
> > > > 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?
Obviously they don't. Does it make WiFi secure somehow?
> > 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 ;)
Ditto.
I can handle it, so do you. Don't expect most list members to replicate
that approach.
Reco
Reply to: