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 :))
https://gchq.github.io/CyberChef/#recipe=To_Upper_case('All')To_Base32('A-Z2-7%3D')
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.
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.
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.
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/
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.
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.
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.
https://www.casio-intl.com/asia/en/calc/products/SL-760LC-BK...
Makes me want to go back to the old casio
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.
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.
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.
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.
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.
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.
It won't protect you from the intention 2fa was created.
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.
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.
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.
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.