On Wed, 31 Jul 2019 16:07:33 +0300 Reco <recovery...@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 <recovery...@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 <recovery...@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
