Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Couldn't the server check for a "trusted IP(s)"?

Two-Factor Authentication is great but even without, it would seem that they could more aggressively lock out any new IP address which is failing password retries several times. (but continue allowing log-in from trusted IP's.)



IPs aren't stable. For instance, the legacy SSID broadcast all across my university assigns you a new (usually different) fully routable public IP every time you authenticate through the captive portal. Some random person enjoys the "trustedness" of your IP at the time of login; you never see it again.

There is a new SSID with WPA2-EAP replacing the captive portal and the usual DHCP/NAT business replacing our massive waste of IPv4 space, but that was implemented last year. This introduces the opposite problem: one person out of thousands can't remember their GitHub password so GitHub mysteriously drops all traffic from everyone on campus.

IP addresses don't identify people, computers, or usefully discrete units of any kind.


While that seems like a logical solution arrived at through a pragmatic approach, it's toeing the line of a really bad practice. IP addresses are not, and should not be, identifiers like this, especially when you're talking about a whitelist. What happens if the ip address changes (happens all the time for the majority of US internet users who have dynamic IP's)? What about if they want to work at a coffee shop?

While it might be possible to do all this correctly, it's just so easy to do wrong that it's hardly worth it. Given that there are existing better ways to do it, it's the kind of thing you probably don't even want to mess with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: