As written, this spec is trying way too hard to fit an arpspoof shaped peg into a wireless sniffing hole. There may be some merit in reusing the list of enumerated devices that we've found to be associated with the chosen gateway, but...mostly, I think it's just silly. For example, this demo (and other arpspoof-based demos) require that the user be connected to the LAN, should be written to work on a wired network, etc. And, if that means we have to ping the whole subnet to find live targets, then so be it.
On the upside, this should simplify how we display captured credentials. Rather than trying to associate them with a given device entry, we can just (for example) include a second, aggregate data table with rows for service, username and (masked) password.
So:
Create a new demo set ("B. TCP session hijacking" or some such)
As written, this spec is trying way too hard to fit an arpspoof shaped peg into a wireless sniffing hole. There may be some merit in reusing the list of enumerated devices that we've found to be associated with the chosen gateway, but...mostly, I think it's just silly. For example, this demo (and other arpspoof-based demos) require that the user be connected to the LAN, should be written to work on a wired network, etc. And, if that means we have to ping the whole subnet to find live targets, then so be it.
On the upside, this should simplify how we display captured credentials. Rather than trying to associate them with a given device entry, we can just (for example) include a second, aggregate data table with rows for service, username and (masked) password.
So:
Create a new demo set ("B. TCP session hijacking" or some such)Move the SSLStrip demo there