You can't even call it bruteforcing if you only have 10000 combinations to guess! 
That's true, and it's even less than 10000, just 6561 combinations since ZERO is not allowed, only numbers 1-9.
Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 39. (Read 966173 times)
That's true, and it's even less than 10000, just 6561 combinations since ZERO is not allowed, only numbers 1-9.
I guess like that yeh, but I was still thinking on the "seed + keylogger risk" - it wouldn't help for that.
Yeh, even with 10 number PIN it would take a few minutes max, so I guess that's completely useless 
(again the device adds big exponentially increasing delay upon every failed PIN, so works fine for that.)
(again the device adds big exponentially increasing delay upon every failed PIN, so works fine for that.)I don't think this sort of thing is linear. Sure it only takes a few minutes to crack the pin alone. Lets say for the sake of argument that it takes 5 minutes. Now imagine that you have a password that takes one week to crack. If you add the pin too that. It doesnt now take 1 week + 5 minutes. The added pin would make it take much longer than that. Idk the actual maths well enough to make a model. But supposing the original password took 1 week to crack (with a given machine) and you added an 8 digit pin to the end of it, that should push it way out side of the range of feasibility for the attacker using the same brute forcing hardware.
Yeh, even with 10 number PIN it would take a few minutes max, so I guess that's completely useless (again the device adds big exponentially increasing delay upon every failed PIN, so works fine for that.)
(again the device adds big exponentially increasing delay upon every failed PIN, so works fine for that.) Yeh, seed + keylogger is probably the biggest risk. I think PIN would be somewhat easy to brute-force if it were 25th word (compared to passphrase), but too lazy to do the math. I can still see it could be an advantage for advanced users though (since keylogger is less effective in that situation.)
Alternatively if the trezor could hold the 25th word in memory just like it does the 24 before it that would be awesome. (or you know the deterministic value that is derived from the seed). Just not writing down the last four words anywhere and remembering just those four is basically this but with the caviat that you have to memorize a new password rather than one you already have committed to memory.
But yea having the pin as a 25th or 26th or w/e word certainly couldnt hurt even if it wasnt enough on its own.
Maybe both. The pin as an extra word plus the ability to have a password that you need for recovery but not for day to day use entering in on mytrezor.com
The pin wouldn't enhance the security because it is too short. You can't even call it bruteforcing if you only have 10000 combinations to guess!
Add a long password and put it in your password manager and keep the seed on a piece of paper, then you're fine. An additional advantage is that you can have several "accounts" on your trezor by using different passwords.
Yeh, seed + keylogger is probably the biggest risk. I think PIN would be somewhat easy to brute-force if it were 25th word (compared to passphrase), but too lazy to do the math. I can still see it could be an advantage for advanced users though (since keylogger is less effective in that situation.)
Alternatively if the trezor could hold the 25th word in memory just like it does the 24 before it that would be awesome. (or you know the deterministic value that is derived from the seed). Just not writing down the last four words anywhere and remembering just those four is basically this but with the caviat that you have to memorize a new password rather than one you already have committed to memory.
But yea having the pin as a 25th or 26th or w/e word certainly couldnt hurt even if it wasnt enough on its own.
Maybe both. The pin as an extra word plus the ability to have a password that you need for recovery but not for day to day use entering in on mytrezor.com
Yeh, seed + keylogger is probably the biggest risk. I think PIN would be somewhat easy to brute-force if it were 25th word (compared to passphrase), but too lazy to do the math. I can still see it could be an advantage for advanced users though (since keylogger is less effective in that situation.)
Anyway, on a different subject, can anyone from SatoshiLabs tell me if an Android version of the TREZOR Password Manager is planned? I love the idea of using Trezor as password manager and would actually encourage others to use it even if they don't have any bitcoins. But Android version seems necessary for me personally. Even if it isn't as advanced as LastPass (easily fills in password in other apps etc), just a simple list + way to get password in Android app would do for now.
Anyway, on a different subject, can anyone from SatoshiLabs tell me if an Android version of the TREZOR Password Manager is planned? I love the idea of using Trezor as password manager and would actually encourage others to use it even if they don't have any bitcoins. But Android version seems necessary for me personally. Even if it isn't as advanced as LastPass (easily fills in password in other apps etc), just a simple list + way to get password in Android app would do for now.
Yes. Seed = private key. PIN only protects for not getting into the device (and does a good job on that, because every invalid PIN adds a serious delay.)
You should add a passphrase though which functions as 25th word. This should be pretty long (let's say 8+ characters), otherwise it could be easily brute-forced with the seed. However, if you forget your passphrase, the funds are gone.
Basically it's much more important to keep your backup seed safe than the device.
You should add a passphrase though which functions as 25th word. This should be pretty long (let's say 8+ characters), otherwise it could be easily brute-forced with the seed. However, if you forget your passphrase, the funds are gone.
Basically it's much more important to keep your backup seed safe than the device.
This is such a bummer. I wish the pin was functionally a 25th word as well. I'm sure there are reasons why it cant actually be, but it would be nice if there were a way it could functionally be. I mean if someone ever got a hold of my seed and keylogged me I would be cooked. But not if the pin was functionally a 25th word.
Yes. Seed = private key. PIN only protects for not getting into the device (and does a good job on that, because every invalid PIN adds a serious delay.)
You should add a passphrase though which functions as 25th word. This should be pretty long (let's say 8+ characters), otherwise it could be easily brute-forced with the seed. However, if you forget your passphrase, the funds are gone.
Basically it's much more important to keep your backup seed safe than the device.
You should add a passphrase though which functions as 25th word. This should be pretty long (let's say 8+ characters), otherwise it could be easily brute-forced with the seed. However, if you forget your passphrase, the funds are gone.
Basically it's much more important to keep your backup seed safe than the device.
Can an attacker gain control of my private keys if he controls my mnemonic seed but my pin remains secure?
Well, I agree, so I would reformulate: I wouldn't recommend people, who do not understand what "rooting" does, to root their phones 
. It is the same as running "sudo su", while not knowing what it does.
. It is the same as running "sudo su", while not knowing what it does.Totally agree with that advice. More people should learn this stuff!
Also, the binary, built from source, is also on github: https://github.com/trezor/webwallet-data/raw/master/android/trezor-app-1.0.1.apk
Brilliant, that's exactly what I was interested in. Presumably this means that there are no Play Store dependencies either (yay). Thank you, thank you, xbach.
Source code is available on GitHub: https://github.com/trezor/trezor-android
Thanks again xbach, I eventually would have looked on github myself.
I really would not recommend rooting your device. A rogue app could access Mycelium database, for example, and grab the private keys.
I disagree with this, there is no logic to it. My desktop computer is "rooted", it's impossible for it not to be. Never had a problem with other Apps run with root privileges have stolen BTC or broken something.
I've only ever used rooted smartphones, and have had zero issues in nearly 5 years. And it's full of benefits: a culture of high quality community-driven software development now exists, and it can be used to protect your privacy, especially from Google. My smartphone runs without a Google Account, or Google Apps. Google have very little footprint in my phone, and I'm certainly not using any Google Services software. I know that rooting phones can easily brick the phone, that's why I'm super careful when doing it.
I strongly recommend that all Android users check to see how well their phone is supported with after-market software, and if the support is good, root. Then say goodbye to Google.
Well, I agree, so I would reformulate: I wouldn't recommend people, who do not understand what "rooting" does, to root their phones
. It is the same as running "sudo su", while not knowing what it does.Also, the binary, built from source, is also on github: https://github.com/trezor/webwallet-data/raw/master/android/trezor-app-1.0.1.apk
Source code is available on GitHub: https://github.com/trezor/trezor-android
Thanks again xbach, I eventually would have looked on github myself.
I really would not recommend rooting your device. A rogue app could access Mycelium database, for example, and grab the private keys.
I disagree with this, there is no logic to it. My desktop computer is "rooted", it's impossible for it not to be. Never had a problem with other Apps run with root privileges have stolen BTC or broken something.
I've only ever used rooted smartphones, and have had zero issues in nearly 5 years. And it's full of benefits: a culture of high quality community-driven software development now exists, and it can be used to protect your privacy, especially from Google. My smartphone runs without a Google Account, or Google Apps. Google have very little footprint in my phone, and I'm certainly not using any Google Services software. I know that rooting phones can easily brick the phone, that's why I'm super careful when doing it.
I strongly recommend that all Android users check to see how well their phone is supported with after-market software, and if the support is good, root. Then say goodbye to Google.
FYI: Trezor Android App was released today. It's just a management app for setting up and configuring Trezor, but with Mycelium, it provides a whole computer-less set up.
https://blog.trezor.io/trezor-manager-app-for-android-5f8b86bfc886#.hcqubj8ct
Link to Google Play Store: https://play.google.com/store/apps/details?id=io.trezor.app
https://blog.trezor.io/trezor-manager-app-for-android-5f8b86bfc886#.hcqubj8ct
Link to Google Play Store: https://play.google.com/store/apps/details?id=io.trezor.app
It's good news, but there are problems:
- Lack of source code (certainly no link)
- Play Store (unknown source and functionality, vendor delivers product as a binary only)
So the claim that the App will work with any Android phone isn't true: there is a requirement that the handset has Play Store software (and, as is often the case with Android apps, may well depend on software libraries in the Play Store app or from Google Play Services). I'm surprised that the developers aren't aware that this is an issue, particularly as they were using a modern Nexus device to test the app.
So, my questions for Satoshi Labs:
- Does the app have source code available?
- Does it depend on Play Store libraries?
- Can it be distributed as an .apk through more reliable channels?
Source code is available on GitHub: https://github.com/trezor/trezor-android
I really would not recommend rooting your device. A rogue app could access Mycelium database, for example, and grab the private keys.
It wasnt having to do with earlier models. My trezor seemed to slow down significantly after the firmware update that came right after the discovery of that attack vector. But now it's seems to be back to the way it used to be. Also I could have just been experiencing an unlucky series of server problems with mytrezor.com around that time. Not sure.
I've found that using MyTrezor with a Trezor can sometimes slow things to a complete crawl, so I don't think it's any fault of the device itself. Whenever I've had issues with my Trezor being slow with MyTrezor, I switched to using Electrum with the Trezor and it was responsive again, so I suspect that most of these slow Trezor issues lie within the MyTrezor web app.There were some issues with the backend server, which were fixed. If there are some issues, you can switch the backend server in the Settings in the myTrezor.com webwallet.
It wasnt having to do with earlier models. My trezor seemed to slow down significantly after the firmware update that came right after the discovery of that attack vector. But now it's seems to be back to the way it used to be. Also I could have just been experiencing an unlucky series of server problems with mytrezor.com around that time. Not sure.
I've found that using MyTrezor with a Trezor can sometimes slow things to a complete crawl, so I don't think it's any fault of the device itself. Whenever I've had issues with my Trezor being slow with MyTrezor, I switched to using Electrum with the Trezor and it was responsive again, so I suspect that most of these slow Trezor issues lie within the MyTrezor web app.Yes it certainly could have been just this.
It wasnt having to do with earlier models. My trezor seemed to slow down significantly after the firmware update that came right after the discovery of that attack vector. But now it's seems to be back to the way it used to be. Also I could have just been experiencing an unlucky series of server problems with mytrezor.com around that time. Not sure.
I've found that using MyTrezor with a Trezor can sometimes slow things to a complete crawl, so I don't think it's any fault of the device itself. Whenever I've had issues with my Trezor being slow with MyTrezor, I switched to using Electrum with the Trezor and it was responsive again, so I suspect that most of these slow Trezor issues lie within the MyTrezor web app. I see. Maybe they patched the hole first, and then improved its efficiency later.
A quite reasonable explanation.
First Trezors did not ship until summer 2014 - two years.
Yes, but if you include the early development phase, the hardware has basically stayed the same for 3-4 years?
I just wonder, if there was a hardware change during that time, what was the motivation behind it?
Just out of interest.
First Trezors did not ship until summer 2014 - two years.
It wasnt having to do with earlier models. My trezor seemed to slow down significantly after the firmware update that came right after the discovery of that attack vector. But now it's seems to be back to the way it used to be. Also I could have just been experiencing an unlucky series of server problems with mytrezor.com around that time. Not sure.
I see. Maybe they patched the hole first, and then improved its efficiency later.
Hm, so has the TREZOR been using the same hardware for 3-4 years now?
No changes in MCU etc at all?
Jump to: