I used totp first time yesterday on GitHub and I don't understand it's point. I had to install otpclient app (from Ubuntu repository) where I typed 4 strings and it spit out one number which I typed back to GitHub. Attacker could do this as well, so the only thing totp does is to prove I can read and write. What am I missing here?
To add the secret to the watchface code, you need to convert it to hexadecimal bytes. This cryptii.com page will allow you to do that conversion. Note you’ll have to enter your TOTP secret in uppercase.
I wouldn't be comfortable entering my TOTP secret into a random web page. In Linux (Ubuntu here, probably other distributions as well) you might have the `base32` and `od` tools already installed (package 'coreutils').
Otherwise the project is awesome (just the watch is fugly :))
Yeah, why would anyone rely on a third-party, and a website one at that for something as simple as base-32 decoding... or generating TOTP. :P
Author of the post here… Cool to see this back on HN! I was trying to provide instructions that anyone could use regardless of platform, hence the choice of web tools (both those linked process the data locally). If you know of a base32 decoder that’s easily available on Windows, Mac and Linux I’d be delighted to update the post.
OpenSSL, base32, basez, C program, Python or Lua script? I have a Lua script that generates TOTP (with base32 decoding), for example. What are your requirements, would either of these suffice?
WSl means Unix command line tools are available on windows as well these days.
This is why I keep uMatrix around still
https://i.imgur.com/9MYqLvj.png
I can quickly disable XHR to confirm websites don't do anything server-side when I don't expect them to.
You'd really need to block fetch(), websockets, WebRTC, all external images/stylesheets/scripts added to the DOM later, and service workers (to prevent the upload from just being deferred). It's not easy to make sure a web page can't phone home.
Well, and writing cookies which would upload at a later visit. And probably a dozen other paths.
Throttling inside of Devtools should do all of those.
If you must use a web app, you can at least use CyberChef, which runs entirely in the client and is widely used in security testing.
Example recipe to do it for you:
https://gchq.github.io/CyberChef/#recipe=To_Upper_case('All')To_Base32('A-Z2-7%3D')
The board is also compatible with the A158W and A171W, they look much better.
I love this, and have thought of doing the same with a dumb smartwatch but... is it good opsec to have top so visible/available? What about losing the watch or getting stolen?
Eh, I keep TOTP codes on my Pebble and am fine with it, they are labeled in such a way that doesn't make it obvious what services they're for.
There's basically no lock mechanism or security on a Pebble, but it's just a second factor.
If you have my randomly generated password, have done your intel to know I might have the TOTP on my wrist, and can physically steal my watch, you've got me beat and I'm okay with that for the convenience it provides.
All security is a balance if the threat risk and the potential loss. I love that you have a mix that works for you while staying reasonable about it.
We all have terrible, terrible tumbler locks on our doors because they are good enough to stop the extremely casual attempts but anywhere with unbarred windows is one rock from "unlocked" and we're generally fine with this for 99% of things.
Security film is another option for windows.
Early totp devices were designed to look like pocket calculators when these things were less well known. But you are supposed to reset the key if you lose the device.
Unless the owner walks around proclaiming, “This is my second factor”, a casual observer is just going to think it is a broken watch.
This is why you create a blog post and share it with the world /s
What's the threat model here? An attacker is going to read this person's blog post, track them down in real life, and steal their watch to get access to their github account? That seems...unlikely.
Also the firmware supports multiple faces. The default face can just be the time
"...so he hid it, in the one place he knew he could hide something..."
Less obvious than a ubikey though right?
if you're wondering why you see a weird ⌍ symbol from time to time on the demo, it's a "small 7" because the watch ties the top and bottom segments of the first and third digits (segments A and D) together.
https://joeycastillo.github.io/Sensor-Watch-Documentation/wi...
it's really amazing how much efficiency they packed in this display. in normal use, these digits only need to display the numbers 0-5 [for the first digit, the clock only needs 0, 1, 2, but the chronometer goes up to 59:59.99], none of which need to distinguish between those segments. technically I guess the chronometer could have gone up to 69:59.99 without breaking anything though, but I guess "one hour" is sufficient? the numbers 8 and 9 also illuminate both the top and bottom segment, so it's only 7 that is an issue.
oddly specific objects is working on a advanced replacement lcd
I think that's this one:
No, that's another LCD meant for arduino boards. It's not compatible with the watch.
GP was referring to the fact Joey Castillo has posted pictures of a custom F-91W LCD in the discord channels. It has more icons and segments, and it can address all of them independently. It's a better, more readable, less limited display. I don't think it's available for purchase yet but hopefully it will be soon.
why cant i get this on my smartest smart watch?
Makes me want to go back to the old casio
A quick search turns up a TOTP widget for Garmin watches https://github.com/ch1bo/garmin-otp-authenticator
yeah i found one called authenticator pro that seems to work. very handy.
Love this project, use it literally every day.
Not too long ago I implemented a new interface for defining the TOTP codes from within the source code. Unfortunately that work has invalidated the instructions in this article. It works like this now:
static totp_t credentials[] = {
CREDENTIAL(2F, "JBSWY3DPEHPK3PXP", SHA1, 30),
CREDENTIAL(AC, "JBSWY3DPEHPK3PXP", SHA1, 30),
};
I also added user calibration to the pulsometer in order to allow it to be used as an asthmometer. It has already helped save lives.
It's also got calibration and thermal compensation features which enhance the watch's accuracy to about 10 seconds per year.
It's got a growing community. A lot of people have showed up to hack on the firmware. Recently someone made an endless runner game for the watch:
https://github.com/joeycastillo/Sensor-Watch/pull/419
The maintainers are really nice people too.
If you're looking for a great open source project to sink some time into, this is it.
I imagine you'd use a common watch battery to power this. Can you comment on the battery life? Could not find it in the docs.
Same battery as the original watch. Most of the watch's parts are reused, including the battery clip and the battery itself. Only the circuit board is replaced.
The original module lasts about 10 years on a single coin cell. The sensor watch can't match that incredible lifespan but it's still very respectable. Power profiling and testing has shown that it has over a year of endurance. There's a builtin battery voltage sensor which serves as a power reserve meter. Maximum power would be 3 V and low power would be something like 2.2 V.
I modified the low power mode timers to make it go to sleep after ten seconds in order to extend it as much as possible. Low power mode means the CPU wakes up once per minute instead of once per second. The only drawback is the lack of seconds display but the truth is I've come to consider that a feature. If I want to know the seconds, I push the alarm button to wake the watch up.
This is awesome. I've always wished someone made something like this for one of Casio's calculator watches
Still waiting for that credit-card sized general-purpose computer.
https://www.casio-intl.com/asia/en/calc/products/SL-760LC-BK...
Pi Zero is smaller than a credit card.
Looks like the WASM emulator does not emulate the classic Casio easter egg, or was I holding it wrong?
Not at all. The reason the easter egg does not appear is this is not actually a Casio Module 593 emulator. It is simply running the compiled sensor watch firmware. So for those words to appear there must be code in the firmware to make it happen. And someone has sent a pull request for it! Unfortunately it was rejected due to trademark concerns.
https://github.com/joeycastillo/Sensor-Watch/pull/102
The sensor watch board is not being fully emulated either. The code is compiled to WASM and run directly. Some functionality is missing. Low power states, for example: the emulator freezes if the firmware tries to put the watch to sleep.
It would be nice if the sensor watch board could be ported to qemu. I tried to do it only to discover I was a little out of my depth.
Finally, the kind of content I come to HN for. =8')
The F-91W is (I think?) the same form factor as the A158W[1], which is an absurdly good looking watch for the price. It goes with everything, stylish yet unobtrusive. I often wear it instead of more expensive watches. If you're concerned about the band snagging arm hairs, it's only done it maybe twice in a year, way fewer than other economy metal bands.
If you prefer a "smoky" alternative, the A168WGG[2] has a gunmetal gray tint to the band, the face is blacked out with clear letters, and the illuminator only lights up the letters. However, the A168 is just slightly larger than the A158, so I don't know if the internal modules fit the same (but larger means more room, so, probably?).
(while I'm nerding out on watches: my workhorse/black band watch is a GA-B2100-1AJF[3]. pretty stylish for a G-Shock, and you get a ton of features for a non-smartwatch. the bluetooth model (vs cheaper models) has more contrasting face colors/tones so it works with more outfits.)
[1] https://www.amazon.com/Casio-A158WA-1-Water-Resistant-Digita... [2] https://www.amazon.com/dp/B08195YQLQ/ [3] https://www.amazon.com/dp/B09YG8F41Y/
so I don't know if the internal modules fit the same (but larger means more room, so, probably?).
It is not compatible, sadly. The sensor watch board requires donated parts from a genuine casio module 593.
A list of compatible watches can be found here:
https://www.sensorwatch.net/docs/
Watches that will not work as they use different movements, although the button layout is the same: A168W, A700W, LA680W, B650W.
In general, if the watch is a 3 button digital Casio that has a nice ‘illuminator’ backlight rather than a side light, it’s NOT a 593 and will not work.
Wow this is really interesting, I work at Nixon and would love to get something like this going on a Nixon digital and/or would possibly be able to get a few free watches if the author wanted to do a similar write up.
dang, this is so cool
It's time to stop using TOTP, it's vulnerable to AitM phishing. Use FIDO2 hardware keys or passkeys instead.
If only I could get this to work with SecurID tokens!
Having to recompile and reflash your wristwatch is probably going to limit the number of things you use TOTP for.
It's supposed to be on another independent device.
Doesn't have to be. While storing them on your computer does not protect you from an adversary with access to your computer, it still protects you against an advrsaey e that intercepts (or guesses, maybe after a breach) your password.
It doesnt have to be yes, but it's called 2 factor auth because of the reason that your computer is 1 factor and another device is 2.
It won't protect you from the intention 2fa was created.
The second factor isn't about a second device. It is additional to something you know (password), typically the second factor is something you have (device, yubikey, etc.).
The idea being that the intersection of {people who can get your password, such as through phishing or other digital attack} and {people who have physical proximity and can steal your physical device} are typically much smaller than the set of people in either category.
Conveniently saved in your browser :) Might not be easy to extract from a logged-out device, but grabbing the device quickly can bypass both "factors" simultaneously.
Makes me wonder how functions like CryptProtectData protect against physical disk access with hex editor. The hash of the login password can be changed to anything and obviously they cannot access the actual password since it should be destroyed after hashing. So unless TPM is involved I don't see how it can be secure.
It derives a key from your password when you log in. Changing the authentication hash will only let you log in, not figure out what the key was.
Oh that's smart, not storing the password anywhere but using the user as an input source for it.
Even if the TPM is involved, it can be cracked. But as with any hack, once someone has physical access to your computer, all bets are off.
The odds of someone stealing your computer to hack into your accounts instead of simply selling it on eBay are practically zero for most people.
E-mail or sms codes are not 2fa then either, if the attacker has your device (presumably with the e-mail app logged in already and the password saved). But this seems like a dubious distinction, its like saying 2fa is no longer 2fa if the attacker has access to the second factor. Thats not particularly remarkable.
You can call it 2sv, though. Two step verification. But a user can certainly chose to use in a way that makes it 2fa by storing the totp secret on a dedicated device. The bottom line for most use cases is that it stops people from getting in even if they guess or crack your password.
With hardware tokens, it still has tradeoffs. What happens when the “user” (read attacker) claims they lost or damaged the yubi key? What factor do you use to verify them before sending a new yubikey in the mail? What happens if someone breaks into the user’s mail? Etc. no method is perfect.
For what it’s worth, whilst your point somewhat stands, generally just 2 devices are not considered 2 factors.
Usually, the factors are considered as:
- something you know (e.g a password)
- something you have (e.g. a device token)
- something you are (e.g. a fingerprint or other biometrics)
Single factor with uses just one of these, which is why you can unlock your phone with either a passcode and a biometric with the same level of security (when talking about factors)
Two factors should have two unique ones of these, and in this case a TOTP generator on the same computer as you are logging in on is fine because the computer counts as “something you have” and the password you enter counts as “something you know”. An attacker who takes your computer still only gains 1 factor (disregarding secure enclaves and password protection etc) and doesn’t have both.
Of course if an attackers manages to access both your password manager and your TOTP generator (whether or not they’re on the same device), then both factors are compromised because the “something you know” factor has been broken due to the things you know being stored somewhere.
Of course, the way you practice the security of each of the factors is important and can vary greatly depending on how you effort you want to put in to it. For instance, keeping TOTPs on just hardware tokens which you never keep plugged in protects against your device being stolen.
In classical proprietary implementations, the TOTP physical keychain is sent you out-of-band via snail mail. Secret is never sent to you electronically.
Modern phone app reimplementation do it in-band on-line, with hope that it has to be harder for opportunistic adversaries to capture that initial handshake.
No they cannot. They should not/will not be able to view that initial TOTP generation code. That is the "secret" that determines what digits are generated at one time.
GitHub sent you those 4 strings while you were logged in and they are now stored on your computer. GitHub will not send them to an attacker that is not already logged in.
You are missing that the TOTP secret will only be presented once during setup.
It is now a second factor because you need to prove possession of the secret by entering the current TOTP code during login. It will not be presented again, so an attacker needs to have been able to intercept the initial secret exchange. (well or phish for it etc.)
You are usually prompted to enter the code during setup to ensure the secret has actually been put into some authenticator and is not immediately going to be lost.