I feel you. I started a small ISP in Montana a few years ago. We're getting into laying our own duct and fiber.
Once I get the machine running, I want to focus on providing tools and information to others looking to do the same thing.
I've been running a Slack channel called ISP School for about a year now to bring together other interested people. Email me at matt@tsi.io if anybody wants an invitation.
Nope. We argued that we were providing data services under the FCC definition of utility. The only real person who got in our way was the city attorney. He said that internet didn't qualify as Montana Code (circa 1950) only mentioned telephone and telegraph.
So we registered with the PSC as a telegraph provider...
I mean you have telephony via IP, and I'm sure there's an RFC to telegraphy via IP. So it's not wrong to say you're providing telegraphy. You're just choosing a very ... deep and expensive tech stack to do so.
Legally, I don't think so. But we did build a little Raspberry Pi based machine with a telegraph key. It needs some more work, but there are people who are legitimately wanting to buy the service.
that's easy -- de-privatize the last mile access networks. run (copious strand count) fiber to everything, lease at standard pricing for every entrant, with operations & maintenance (and plant depreciation) built in.
I think the hardest thing about a municipal network like that is having a government organization competent in managing it. Streets are still mostly functional with potholes, but a network certainly isn't.
We're operating on a brand new municipal network right now and it's not awesome. In an effort to be fair to all parties, no one is actually in charge. The network operator is separate from the construction contractor who is separate from the bandwidth providers. It's extremely frustrating.
They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password.
You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
I never said it was a good way of storing passwords. It reduces entropy. I'm just saying there is way to both have hashed password storage as well as "asking for 3 random letters of you password at login".
You replied to a comment saying "That implies that they store plaintext or something reversible." You posted about hashing in a way that implies that comment is wrong. But that comment is completely correct. Taking three characters and hashing it is easily reversible. And then the attacker gets to log in.
The question is not whether on a technical level something got hashed. The question is whether a hash protects the password against brute forcing. And the answer is no.
Password hashing is used to prevent the brute forcing when the attacker already has the copy of the password database, and is free from any failed attempt limits and timeouts. And in this case storing hashes of all 3-letter combos is basically useless, since all those hashes are very easy to bruteforce.
Ah ok, so you're starting from the assumption that the site has already been owned and the attacker has the hashed passwords. In which case yes, it does make it easier.
Can't it be achieved by this simple steps?
Consider ur password is y.
a) f(y, i) = a func that gets i'th character of a pass. y;
b) hash(x) is ur hashing func;
c) x0 = hash(y);
d) concat(a, b) - concatination func;
1. x1 = hash(concat(f(y,1), x0));
2. x2 = hash(concat(f(y,2)+x0));
.
.
etc
Store in DB
id position hash user_id
1 0 x0 1
2 1 x1 1
3 2 x2 1
Many banks (I work for one of them) follow reasonable best practices, allow or require strong passwords, store them safely and require sensible second security factors. Others are decades behind in security, using nonsensical security schemes like the ones morgante and mng2 described above or requiring your password to be letters and numbers only between 6 to 8 characters.
If you care about security, stick with the banks who do as well. Make sure their password guidelines are in order, go with the ones that make you use a second factor, and if you ever see any hints they're storing your password in plain text, run.
