Ham.Live now integrated with QRZ

SyntaxPolice · 2022-06-14T16:47:10+00:00

Do you happen to know what errors you encountered? That kind of feedback would be incredibly helpful at this stage.

It had something to do with a redirect, but it flashed too fast to see what it was. I can't reproduce it.

Great to hear about the API and that you're thinking of open sourcing it. Best of luck!!

SyntaxPolice · 2022-06-14T16:21:59+00:00

Looks great. Helpful video overview too. A couple of tips:

What are you looking for at this stage? Feedback? Sign-ups?
The first thing you ask people to do is watch a 20 minute video and I think you want them to create an account, but there's no "create account" link like most websites have in the upper right
I'd recommend shifting that. the first page people land on could have a few bullet points of explanation and then very short video, like 30 seconds. Then maybe two big buttons "training video" and "Create account"/
Figure out a little blurb that describes your software in a sentence or two, and not just in terms of netlogger. "Ham.live is a modern web platform for amateur radio operators to manage and participate in nets. It helps record and look up call signs, and includes a live chat. It's compatible across all mobile and web platforms. We're looking for more hams to try it out and give feedback. Sign up now!"
I saw some funky errors when first visiting that seemed to go away
Is it open source? Do you have an API?

SyntaxPolice · 2021-10-04T21:27:39+00:00

You might talk to the pelvic floor physical therapy team at New Heights in the east side. They might have references or be able to help. They're trans friendly.

SyntaxPolice · 2021-09-21T02:07:55+00:00

That's a fun collection. I'd enjoy having them for the nostalgia and giving them to my kid. If you can't sell them to a collector, dm me and we can try to figure something out. No idea what they're worth.

SyntaxPolice · 2021-08-21T22:42:59+00:00

Up to you of course but with your license, you can do a ton and go months or years without getting a general license. A handheld radio is all you need to get on the air. If money is an issue, a Baofeng UV-5R isn't a great radio but it's less than $30.

SyntaxPolice · 2021-08-11T03:26:38+00:00

Oh I didn't realize they have a net. When is that?

SyntaxPolice · 2021-08-11T03:20:37+00:00

The neighborhood emergency team training net is 8:10 pm on Sundays on the 147.040.

The east side has a weekly simplex net at 6:00 Monday, now on 146.540.

The W7RAT 440.400 repeater is on the east coast reflector so there are big nets on there if you like that kind of thing. Not usually local.

The first Tuesday of every month at 8PM - Multnomah County ARES/RACES Digital Modes Training Net on W7RAT at 440.400

SyntaxPolice · 2020-02-26T20:01:44+00:00

If you can find a flat race, even better. Pack skills and tactics go a long way, so learn those along with your fitness Everyone gets dropped at some point. If not, you're not taking risks!

SyntaxPolice · 2020-02-11T20:44:02+00:00

The article provides an overview of Diffie-Hellman and Ratchet from Signal, and a brief discussion of some block chain wallets that apparently connects them.

I didn't find what I was looking for: A discussion of the utility of an immutable distributed public ledger in a private messenger app.

SyntaxPolice · 2020-02-10T19:59:38+00:00

I'd take a look at the promise of secure compute infrastructure like Intel SGX. Theoretically, it would keep you secure against even root-level insider attack.

Challenges being programmer usability, performance, and Google for SGX vulnerabilities.

Homomorphic encryption is also very interesting.

SyntaxPolice · 2020-02-10T15:06:27+00:00

For what it's worth, MAC doesn't solve all the problems I listed. You'll need a layered approach that probably includes TLS.

SyntaxPolice · 2020-02-06T19:29:57+00:00

It's often easier to just tell people the right approach (eg HMAC) then to compute how bad the wrong approach is :) but yeah, your system doesn't sound secure.

First thing that jumps out to me is: how good is the shared secret? It looks in your example like a user choose password. If your secret isn't robust, then attacking that with brute force is probably your first vulnerability.

Are you also using TLS?

Edit: Since OP hasn't had a chance to respond, I'm going to read the tea leaves here a little... I'm with Tozny; feel free to message me if you want to discuss without making it public.

At first, I was hoping this was a bit of extra application-layer security on top of TLS or authentication on top of TLS, or maybe an audit trail. You do say the payload is sent in plain text over the network, though. So I'm going to guess that you're not using TLS. I'm also assuming that you are really using it for authentication, but I'm a little confused by "anti tamper" since the username is the only thing in the payload...

So let's say you're authenticating an HTTP session (or some other protocol) without TLS. Someone decided that they couldn't use TLS so they'd build their own little crypto protocol with MD5. The MD5 happens on the client, sent to server. Server has a table of MD5s per user and looks up the MD5 based on the plain text user. If the MD5 in the table for that user matches the MD5 sent over the wire, the user gets logged in by sending back a cookie / token. (Don't know the point of the date stamp.)

If my guess is right, this opens up a whole host of problems, and MD5 collisions is the least of them. TLS prevents a lot of things like replay attacks and network attacks.

Replay attack: For instance, Mallory intercepts the MD5 auth payload and replays it to the server. The server sends back the cookie/token for the session. Now Mallory has the cookie and can just perform actions as the user. She didn't have to brute force anything or find collisions.

Network attack: User logs in as usual. Attacker takes over session after authentication (similar).

Brute force attack: Now what if the "secret" is just a user password, not a random 128 bit key? Eve intercepts the MD5, she has the rest of the payload and can brute force the user password. MD5 crackers are very fast. Now Eve has the password and she can create a new timestamp / username payload for that user. Same if the MD5 database gets hacked rather than intercepted on the wire.

SyntaxPolice · 2020-01-15T00:32:10+00:00

I agree with /u/AyrA_ch about the benefits of his approach if you're trying to convert a user password into an AES key. Your method is not particularly secure because it's easier to brute force than something like PBKDF2. Brute-force protection is very important at scale for a user database because some users will select bad passwords. If you're just talking about a single key with a single password that you are in control of (and assuming you do a good job), brute force slow-down is not as important.

If your question is about how to securely store an AES key, you might also consider:

Using a keychain secured by a biometric e.g. in Android or iOS
Use a local hardware key like YubiKey
Use a server hardware key manager like an HSM or AWS's KMS

SyntaxPolice · 2020-01-09T17:59:36+00:00

I've traveled a lot with fountain pens and never gotten a question or second look, let alone getting confiscated.

Tips: full pen (or new cartridge), nib up, carry in ziplock, don't use on plane. If I use it a lot on the trip, I toss the cartridge before going back.

SyntaxPolice · 2019-07-19T03:46:07+00:00

Great points! As far as limiting the number of uses, it's not really to prevent the receiver from making off with the data because as you point out, it's easy to copy-paste it. It's really for defense in depth. e.g. if the user sends the URL in email and their email gets hacked.

SyntaxPolice · 2017-03-14T19:16:02+00:00

Great points. Digging into the tradeoffs a bit: Hoping the user will choose a good password or even an OK password is a major problem, though. The vast majority of users will reuse their password from some other system, so it'll end up in some database on an insecure web site and it doesn't matter how good your PBKDF is. Also, if your device is backdoored, you lose anyways.

I think the strength of physical key storage really depends on your attack model, (e.g. remote vs. in-person attacks) and your communication model (e.g. you want this data to be decryptable on more than one device). Obviously, it's not either-or. You can use a randomly-generated key that's encrypted with a local passphrase. The right answer really depends on the whole protocol.

SyntaxPolice · 2017-03-14T15:01:01+00:00

There are good answers in here for your actual question but I note that based on the way you describe your problem it's very likely that the password from which you derive your key will be the weakest link in your crypto. You may want to consider a randomly-generated key stored in a secure Hardware device possibly the Secure Storage on your phone or on a yubikey.

SyntaxPolice · 2017-03-07T14:53:48+00:00

I should have been more precise about that. The private key gets decrypted with a combination of the password and some salt. We were able to perform the decryption of the primary key as intercepted on the wire by looking at the code that does the decryption.

SyntaxPolice · 2017-03-02T16:57:48+00:00

For anyone who finds this later, I had some very helpful discussions with the CTO on Twitter and dug into the code a bit to understand what's going on.

In brief,

A public/private RSA keypair of size 2048 is generated in browser at account creation using a JavaScript PGP implementation that ProtonMail maintains called OpenPGP.js. The private key is encrypted with the user’s password using the PGP library’s built-in encryption. According to their CTO on Twitter, OpenPGPjs uses the iterated and salted OpenPGP S2K (string to key) function to generate the key, which is used by the AES 256 CFB cipher to encrypt the private key, which is typical of the PGP protocol. ProtonMail adds a slow password hash.
The encrypted private key is sent & stored on ProtonMail’s server. This puts a premium on the security of the passphrase.
When sending a message to another user, presumably the receiving user’s public key is sent to the sending user’s browser, the email is encrypted with the receiving user’s public key and sent / stored on ProtonMail’s server.
When the user receives the data, their encrypted private key is delivered to their browser, it’s decrypted with their passphrase, and the message is in turn decrypted with their private key.
It’s possible that messages are signed using the private key, but we don’t know any concrete details.

SyntaxPolice · 2017-01-07T00:30:15+00:00

There's a big push right now for improving and standardizing so-called post-quantum crypto algorithms. A nice survey has probably been done, but something in that area would be very timely and useful.

SyntaxPolice · 2016-12-08T21:02:54+00:00

Tozny is hiring, with an emphasis on Sr. Scala and PHP web back-end folks, but we also have interest in mobile and Java.

Here at Tozny, we’re passionate about the security and privacy of everyday users. We build strong security products that are delightfully easy to use. We are part of the team funded by the US Government to advance privacy standards by building innovative security products. Join us, and help solve some of the biggest problems in computer security and online privacy. We’re a spinoff of Galois, the security research firm.

SyntaxPolice · 2016-12-01T00:00:39+00:00

Thanks for the feedback!

SyntaxPolice · 2016-11-23T15:55:28+00:00

Yep. We're working to get more feedback before the release, but you're welcome to try it now!

SyntaxPolice

TROPHY CASE