Why not? Arduino became popular among DIY enthusiasts, a lot of cheap arduino shields were produced, so many other dev boards now have compatible pinout.
Pwnagotchi [0] is quite cool. It's kind of like tamagotchi, but you need to feed it Wi-Fi handshakes. It's using Raspberry Pi Zero and E-Ink display module.
stretches or cost is number of hashing rounds, so not related to password length.
bcrypt has 72 bytes password length limit [0]. If the password is shorter, it gets extended to 72 bytes anyways, so longer passwords (10 chars vs 70 chars) are not making time difference.
The password can be pre-hashed to allow arbitrary sized passwords [1], but I don't think 10 chars vs 10000 would make a significant difference. I think most of the time will be spent on bcrypt rounds, not on pre-hashing.
> Happened to me.
While trying to find stretches quote, I found this post [2], so maybe it was not bcrypt? :)
I don't know much about DDoS protection, but wouldn't it be possible to add token to UDP packets? So the client first connects to a TCP server and gets 4 bytes token unique per IP. Every UDP packed should start with that token. Since an attacker with spoofed IP can't get a valid token, their packets can be ignored with a cheap check. Might be even possible to use iptables/XDP for it?
We already have a token in the protocol and this is indeed a viable way to help drop invalid traffic. However, none of us are really experienced enough with the networking stack of the linux kernel (nor are these things very well documented) to craft a conntrack module or an XDP program to parse the header and keep track of the assigned tokens. Dropping these any later than the nftables stage is just not enough as we already do that.
We have a small team who work on this project during our free times and most of us just don’t currently have the time to dig into conntrack/nftables/xdp.
I found this tutorial [0] and example [1] how to read/update BPF hashtable data from python bcc module. If UDP packet structure is not too complex, it might be not too hard to implement I guess.
It is a standard practice to have a "login server" and a separate "game server". The login server generates the token, and notifies the game server to accept it. The login server handles a queue, and can throttle login attempts. The login server can handle load balancing for multiple game servers, redirecting logged in players to different game servers. Its possible to run multiple login servers too, and restrict the access to specific login servers geographically and to run them with different providers.
Seems interesting, but I got stuck by the door. If you don't know how to progress, the only way is to spam click every action on every word. Like "use gas lighter" reveals debris, but not the door. And to see the door I had to spam click until I found "inspect place". Also lighter can run out of gas, so you can't really spam click.
More context to why using apps, not websites or email:
Smart Voting website is hosted on Google App Engine (appspot.com). The Russian government had no ability to block it for long time without affecting other Google services, since ISPs could block mostly by IP and via DNS spoofing.
To block reliably by domain they would need to have DPI (deep packet inspection) hardware, and most ISPs had no DPI, since it's expensive. Even if they had it, they could only block by domain/ip, not by traffic signatures and reaction time was relatively slow.
Now they improved censorship infrastructure and basically building Great Firewall. As I understand government controlled DPIs are now installed on Internet exchange points. So it's easier to block specific domains and protocols. Recently they:
- were throttling Twitter (and every website with t.co substring, yeah)
- blocked some opposition websites hosted on Appspot
- DNS over HTTPS (DoH) servers used in the app (Google, Cloudflare, OpenDNS)
- Bunny CDN, used in the app
- docs.google.com, telegra.ph (voting list was published there)
- DHT and BitTorrent
- started blocking some VPN providers and attempted to block Wireguard protocol
I think some of blocks (e.g. torrent) were used to test capability. Now that they can slow down websites and block more accurately, they have more leverage over tech companies.
Apps have more ways to avoid blocking than websites and PWAs. E.g. by getting endpoints/data via updates, notifications, domain fronting. So the obvious next step was to attack app stores.
---
You could enter your email on the website, but some of the emails got leaked. Considering many people used personal email addresses, it was possible to combine it with other leaks/DBs to get more personal information. Police visited some people registered on the website. So I guess people trust less giving their email addresses now.
The same thing happened to me a few years ago. I used DigitalOcean's Docker image and it had some message about UFW in motd, so I assumed it works with Docker. So I created a container with passwordless mongodb and it got wiped in a few hours.
And DO still have this in motd for newly created droplets:
Welcome to DigitalOcean's 1-Click Docker Droplet.
To keep this Droplet secure, the UFW firewall is enabled.
All ports are BLOCKED except 22 (SSH), 2375 (Docker) and 2376 (Docker).
> Note: The default firewall for the Docker One-Click is UFW, which is a front end to iptables. However, Docker modifies iptables directly to set up communication to and from containers. This means that UFW won’t give you a full picture of the firewall settings. You can override this behavior in Docker by adding --iptables=false to the Docker daemon.
So the makers know of the security issue, but still leave it in by default? That's bad. Either fix the issue, or put warnings all over the place that cannot be missed to inform the user.
This is just what another poster commented on, sacrificing security for ease of use.
Yeah, I reported it to DO support and suggested to add a warning, but seems like it was never added.
DigitalOcean Support Thursday, March 15, 2018 9:53 PM
Hello,
Thank you very much for bringing this to our attention.
I will create an internal escalation to our images team to review this. :)
[...]
