Dear @jacobgadikian, @megadrive, @ericet, @michelangelo3, @condeas,
now a few months have passed on BLURT, and the stake in our wallets has grown.
This makes the issue of "security" even more important.
There is also the fact that after HF3, the powerdown period will only be 4 weeks. This brings a little more insecurity.
After the fork from Steem, recovery accounts could not be automatically entered in our BLURT accounts, because most accounts would have had Steemit written there.
Thus, in our BLURT-Accounts the field "recovery account" is empty.
@ericet was so helpful and built a little tool that we can use to determine a recovery account.
But as my information stands, there is no function yet to be able to recover an attacked account as well.
Now I have a few questions. The answer to my first question is the most important to me.
Would the founders or/and developers be able to recover an attacked account in which the field "recovery account" is empty? And would they do it as a help for the owner of the account?
In the case that 1) is not possible, how should a compromised account be recovered?
Are there any plans to implement the account recovery feature with HF3?
Are there any plans to implement an additional idendification (2FA) because of the shorter power down period after HF3?
One other supplemental question:
@condeas gave me the following idea through a comment, and I would be very interested in your opinion. The question is whether I could substantially increase security through a construct of delegation.
For example:
- I create a second account.
- I power down with my main account.
- I transfer all BLURT to my second account.
- From my second account I delegate all BLURT to my main account.
Would both accounts then be much more secure against attacks because my main account has only a delegation and my second account has all BLURT assigned as delegation?
Thank you very much for your attention and I am looking forward to your answers.
Best regards, @double-u
Wao everything that has been commented in this publication is interesting. It is good to know these things and that they are working to improve. Creating another account and delegating seems like a good idea. I definitely always learn something from your posts. :)
I'm very pleased! Thanks!
Hello @ double-u. I will not be able to be in your publication because I will be preparing everything for the end of the year dinner, however from now on I want to thank you for all the support in this year 2020 to me and wish you the best for next year, that you achieve all your goals and that May you and your family be blessed and enjoy much life and health. Receive a big hug from Venezuela from me and my family.
Thanks for everything and Happy New Year.
Congratulations, your post has been curated by @r2cornell-curate.
Also, find us on Discord (https://discord.gg/BAn2amn)
https://discord.gg/BAn2amn
Merry Christmas Sir
@double-u sirI could not post on Blatter for a few days due to illness. I am very happy to post today and I like your post very much sir. And thanks for sharing this post with everyone, sir.
Interesting question and topic.
were can we see the set recovery account. I guess mine must be steem then
when we use ericet's tool to change our recovery account, we need our master password. Is it safe to use it there or should be better change the master password after using it in that 3rd-party tool?
Here is a tool that @ericet already created to change recovery accounts https://ericet.github.io/BlurtAccountRecovery/ but remember if your recovery account ever gets compromised and you land up changing the password on any other account that uses it as a recovery account, then the attacker can gain access to that account too.
Also recovery accounts lead to vulnerabilities with 3rd party apps, say for example there comes along a new app called blurtgame, this app gives away free accounts and by default makes blurtgame the recovery account, the uniforned user has no idea of this or the implications.
Then one day blurtgame sells its app to another party, who is not a good actor, now the bad actor is the recovery account for many users that created accounts via its service, each time a user changes their password for whatever reason, since it is the recovery account, blurtgame can, in the next 30 days, recover that person's account and lock them out of it and steal the funds.
As @jacobgadikian said to me earlier, account recovery is a gimmick to make users feel safe where in fact there are many pitfalls "gotchas" that can catch out the users if they are not diligent.
Bitcoin for example does not have recovery accounts, so it has less attack vectors. I like to keep my BTC split between 3 wallets, so if I lose access to one I don't lose all my funds.
Hi @megadrive,
first of all thank you very much for your answers!
I'm just talking to Jacob now and may have some feedback for you later.
So, sir! Should we make another account and split our BP or liquid blurt in both accounts? In that way, our voting power will go down, hence curation reward.
While on the topic of storing BTC, I would like to plug my favorite wallet:
https://opendime.com/
Opendime makes your BTC physical. If your opendime doesn't get stolen, it's yours. Same risk profile as physical cash or gold. strongly recommend.
The questions are very important and the answers can also determine the interest of new investors.
Everyone wants to invest when on a safe platform.
I am di sure the founders @jacobgadikian and @megadrive are also ck concerned about the funds of investors. So they would have been making some plans to ensure the security of an investor's fund.
All dvelopers hand are on deck, i know.
I hope @jacobgadikian or @megadrive will give you a warm answer.
Hallo Werner
Von der Logik her finde ich es gut wenn man ein neues Konto erstellt diese Keys nach dem erstellen sofort erneuert und dann an das Hauptkonto eine Delegation macht .
Das Konto mit dem man Arbeitet und den Aktiv Key oft nutzt muss nicht so dick bestückt sein mit Blurt !
VgA
Wenn dies der Fall ist wegen 2nd account, ist dies nur für die Großinvestoren sinnvoll, für die kleinen Fische jedoch wahrscheinlich nicht, da die Delegierung eines Teils seines BP weniger Voting Power und weniger rewards bedeuten würde.
Sicherlich nur für große Accounts ich muss mir da keine Gedanken machen
Lololol!... ich auch nicht, willkommen im Klub.
Dem stimme ich zu :-)
Useful question and answers (in the comment section). Worth reading.
At last got one post in my feed which actually real blurt-related post. Thank you.
I had a few of the questions in my mind. Thanks to you, got a few answers.
With Recovery Accounts missing it is more important to change your keys. I have now 3 diffrent keypairs ,1 for each chain.
I dont know if Recovery Accounts are realy a Security Risk @jacobgadikian but i am not a developer.
On the one hand it feels good to know there is still someone I can turn to if I have made a really big mistake.On the other hand what do I do if that person is no longer active and I can't reach them.We all know how quickly it can happen that someone is no longer active.
Possibly it could solved better with a 2 factor authentication ,which would mean however surely a quantity expenditure.
So, this debate is in fact why I don't get into this stuff publicly much.
Math isn't up for debate my friend :pray:
Thanks @double-u, here are some brief answers
A: If the recovery account is empty, I do not believe it can be recovered by anyone, the idea was that people be responsible for setting their own recovery account and no central entity being responsible for it. I do think there needs to be some training on how to set this, so maybe someone can do a post and we can feature it.
A: There is no way currently to recover if user has not set a recovery account
There is already an account recovery feature on chain, just need to create a user interface so non-devs can use it, currently if you are the recovery account owner you can recover keys for people only if their password has been changed in the last 30 days I believe. Thereafter no more recoveries possible.
A: this is not really compatible with blockchain technology as it will rely on a third party 2FA app that could go rogue, the chain needs to be self-sovereign so needs to have little interdependence with external systems.
The best advice is to split your stake into multiple accounts, set recovery account for all to another dormant account whose keys never key used on any interface, You can delegate all your stake to your main account from the separate accounts and can set a witness voting proxy to main account for each.
I will also talk to @ericet about a recovery UI tool.
Hi @megadrive,
first of all thank you very much for your answers!
I'm just talking to Jacob now and may have some feedback for you later.
Disagree on splitting stake it's not necessarily the best practice. Best practice will be determined by his unique circumstances.
It might be best.
Security is so important at this point.
Since this platform was built from steemit, and we didn't steal it, but was with the support of steemit administration team, our administrative team should highlight the harms steemit fork would cause us and work out modalities on how to do it in a way to favour us as well.
Looking into the issue of recovery account, I believe @megadrive is on top of his game, he'll not let us down. We equally have people like @jacobgadikian,@ericet, at el, we're sure of the platform's safety. All we need do is to join hands to give them the necessary support to get it done.
Very important questions! I am very curious about the answers. I am surprised to hear that the POWERDOWN will be shortened to 4 weeks.
It's a matter I'm personally ambivalent on, but ultimately supported.
Now I am wondering if it can be parameterized, like our fees.
I just saw that you have not entered a recovery account either.
I view recovery features as a security risk, and I want to talk to you directly about all matters discussed here.
If there is stuff on the chopping block, certainly to me, recovery is one of the things on the chopping block. But that won't happen soon.
Can we please set up a time to talk?
These are all very good points and I'd like to discuss them with you at length.
The super short version be like:
Last week I ran our key privilege stuff by a cryptographer-friend and his feeling was the same as mine.
BIP39 is better, and the privileges make no sense.
But we won't be moving to bip39 on blurt, there is no practical way to do it.
Hi Jacob,
unfortunately I do not understand this expression "chopping block".
Do you not want to discuss these issues here publicly?
EDIT:
Maybe I also misunderstood ...
I will be back here in 12 hours. Thank you!
Is that good for you?
yes, 12 hours is okay. But I certainly would prefer to speak by DM.
I can advise you on stuff here, publicly, but a lot of what I have to say, can be easily misconstrued.
"chopping block" -- I have always viewed recovery as a risk, I would rather remove it entirely.
There is surely stuff I'd rather say privately, as I am aware that these are super hot-button items in graphene.
I would also say it publicly, but doing that will take a lot more work and a lot more words than first, talking with you about it, learning what you're feeling and thinking, and then publicizing our conversation. Security matters are so easily misconstrued. There is history here for me:
https://steemit.com/life/@inertia/q437x6
Read the post from Dan. Then feel free to read my embarrassing inital post (I later edited it for politeness and sanity) but to do so you would need to use a block explorer. I paid dearly for pointing out these issues, both personally and professionally.
And I knew what I was getting myself into, building Blurt on graphene. And that is why:
Dan basically tossed me from Steem but the thing is, he did use non-canonical sigs, heck even blurt still uses those same non-canonical sigs.
And I can tell you this much: far as I can tell, they work. But they sure as hell are not normal. Signing and encryption schemes like secp256k1 are supposed to work in ONE CERTAIN WAY. Let's just review the canonical secp256k1 scheme vs Blurt/steem/hive:
Canonical:
https://www.npmjs.com/package/secp256k1 (nodejs, runs on servers, calls C libraries) ----browser-----> https://github.com/indutny/elliptic (pure javascript, runs in the browser, can be called from secp256k1 for isometric implementations)
**JS definition of secp256k1 ecdsa curve **
https://github.com/indutny/elliptic/blob/e71b2d9359c5fe9437fbf46f1f05096de447de57/lib/elliptic/curves.js#L169-L206
Actual signing inn the elliptic js lib
https://github.com/indutny/elliptic/blob/e71b2d9359c5fe9437fbf46f1f05096de447de57/dist/elliptic.js#L2255-L2318
Doing a sig from the secp256k1 lib, which in turn calls elliptic if you run it in the browser:
Look how clean!!!! Process is very clear.
here is how we sign things on Blurt:
https://gitlab.com/blurt/openblurt/blurtjs/-/blob/master/src/auth/ecc/src/signature.js
lolwut? I know zero people who know what is going on in signature.js with a high degree of confidence.
The auth hierarchy is wrong. Usernames are wrong. That is what enables censorship, you see. It is literally how @baabeetaa and I pulled out the steemit, inc accounts. He built the ventilator, and I told it what to ventilate, and then the fart was cleared from the room, but the trouble is that farts can be cleared at all.
Furthermore, when I attempt to use industry standard secp256k1 implementations on Blurt keys, I fail. We do some crazy, strange things in that signature library, and that is never good.
And what I want to discuss with you 1:1 is how I plan to mitigate that and how it effects the long term future here.
Some stuff, I don't think it should be said, lest I trigger a double whammy of angry Larimer-Hive-Steem folk down on my head again.
But facts remain facts. They may displease people, but surely they'll remain facts.
The way we use secp256k1 is unique to larimer-chains but not in a good way.
further
I can also advise you on storing your BLURT, and that is likely better as a 1:1 conversation, too.
Let's do twitter DM, please:
https://twitter.com/gadikian
but there is also telegram:
@jacobgadikian
and facebook:
https://www.facebook.com/jacob.gadikian
LinkedIn
https://www.linkedin.com/in/jacobgadikian/
From there we could move to an even more private means of chatting, like Signal or Tox.
And to quote CZ of binance:
Funds are SAFU
--just everything to do with encryption and the security model is..... quite unusual. And unusual is not a great thing for encryption. You want to follow the industry standard to the exact letter, and after you do that you should pray to all of your favorite gods, because encryption is super hard even if you follow the exact industry standards.
Hi Jacob, @jacobgadikian
now I am back.
Oh, sorry about that! I did not know that I wrote on such a sensitive topic.
Thank you for all the work you've had now with your answers!
I will be happy to write with you 1:1 on another channel. I will contact you there.
To my knowledge of the background of codes you must not overestimate me. I can use a PC with Word, Excel and e-mail. That's all ;-)
See you
Well so it's not actually that sensitive, it shouldn't be anyway.
But, because things were done just so strangely, it is. I'm very comfortable publicly saying that alert does things in a strange way that we inherited from Dan Larimer....
however if we look down below at people's comments, one of the things that we can see is you know people rapidly get concerned about this kind of stuff and I want to talk about it at all, it has to be in some great detail mentioning exactly what the risks are, and are not.
Essentially, the weirdness really isn't much of a risk here.
Though way to keep your blurt safe in my opinion is to design and follow a strategy that works for you
Look the coin that I am most secure about owning, as in it won't get stolen from me, it is in my possession, is Bitcoin, stored on opendime.
Nobody knows where my open dimes are,And as long as I keep them in my physical possession, I know that that Bitcoin is 100% mine.
Hi @empato365,
but, I did write that I mean we currently do not have a feature implemented that can be used from the recovery account to recover the attacked account.