I'm also still bothered by the fact that you don't seem excited about associating IPs with sessions so that guests without cookies could at least be tracked...
I'm not excited, the whole concept is fundamentally flawed.
Maybe when IPv6 is widespread and everyone's using it we can reconsider it but there are so many foibles attached to using IP as 'detection' that it's unreal.
* there are still users shuffled behind a massive network so that they have different IPs over time, sometimes per page, though this is distinctly less common than it used to be.
* users behind any kind of proxy will be lumped together under fewer IPs, meaning that for example the one forum I work on will only ever show 1 guest because of way requests are routed to it behind the firewall, it only ever sees 10.0.0.2 as the incoming IP address. EVER. Kind of renders everything else moot for that user.
* it still treats different Google (+Bing+Baidu) bots as separate users.
* spammers can and will inflate this artificially.
* mobile users are still likely to be incorrect, especially if they happen to be on the move between cell towers, again it's routed through a proxy, though a much larger one.
IP != identification of any kind.
Ideally, we would issue sessions for guests that allow for cookies. Meaning that they'll never get a session started on first visit, but if we (still) attempt to set a cookie, the next page they view will then start a session, so they should be able to log in, right...?
That's where it gets complicated. If we don't track sessions for guests, they can still log in, with the session and cookie generated after successful authentication. All we lose at that point is the ability to validate that they came from an existing page to log in (but that's not really a massive prevention layer)
As far as handling failed logins and preventing more than 3, that would have to be done in a session but there's no reason we need to start sessions all the time for every user/guest/wandering monkey, which is where I'm going with this.
Though, disregard the whole cookie aspect. For the purposes of what I'm suggesting, the fact that cookies are used is almost irrelevant; the fact we're doing sessions at all for guests outside of logging in is a massive amount of per-request overhead that I don't think we need to handle since all we're actually doing in those cases is analytical stuff and vague storage.
What, exactly, do we need to store in the session regarding mobile detection?