Allekirjoitus ilman kaasumaksua voi silti antaa oikeuksia

Lompakon allekirjoituspyyntö voi antaa toiselle osapuolelle mahdollisuuden käyttää tokeneitasi myöhemmin, vaikka itse allekirjoituksen yhteydessä ei näkyisi kaasumaksua. Maksuttomuus kertoo vain siitä, ettei sinun tarvitse maksaa kaasua juuri kyseisessä allekirjoitusvaiheessa. Se ei kerro, mitä allekirjoitettu viesti oikeuttaa tekemään.5, 6

Kaikki allekirjoitukset eivät ole samanlaisia. Osa viesteistä liittyy esimerkiksi kirjautumiseen, osa taas voi olla tokenin käyttöoikeus tai siirtovaltuutus. Vaikutus riippuu viestin sisällöstä, standardista ja sitä käyttävästä sopimuksesta. Jos et ymmärrä pyyntöä, turvallisin päätös on jättää se allekirjoittamatta ja selvittää ensin, miksi sitä tarvitaan.

Mikä ero on viestillä ja verkkotapahtumalla?

Kun lähetät lohkoketjuun tapahtuman, siihen liittyy yleensä verkon määrittelemä maksu. Viestin allekirjoittaminen on eri toimenpide: lompakko tuottaa allekirjoituksen tiedoista, jotka sovellus voi saada käyttöönsä ilman, että allekirjoitus itsessään heti muuttaa lohkoketjun tilaa. Joku muu voi myöhemmin lähettää allekirjoituksen sopimukselle osana erillistä tapahtumaa.5, 7

Tämä ero voi olla hyödyllinen, koska käyttäjän ei tarvitse aina lähettää jokaista välivaihetta itse. Se voi kuitenkin myös hämärtää riskin. Jos lompakko ilmoittaa vain, ettei allekirjoituksesta peritä kaasua, tieto ei vielä vastaa tärkeimpään kysymykseen: mihin viestiä voi käyttää?

Allekirjoitus ei automaattisesti siirrä kaikkia varojasi eikä jokainen viesti anna käyttöoikeutta. Toisaalta viestin hyväksymistä ei pidä käsitellä pelkkänä harmittomana kuittauksena. Lue pyynnön tarkoitus ja kentät samoin kuin lukisit sopimuksen ehdot ennen hyväksymistä.

Permit voi asettaa käyttöoikeuden

ERC-2612 on esimerkki token-standardin laajennuksesta, jossa omistajan allekirjoittamalla viestillä voidaan asettaa tietylle käyttäjälle tai sopimukselle tokenin käyttöoikeus eli allowance. Standardin mukainen permit-kutsu tarkistaa allekirjoituksen ja muut ehdot ja päivittää käyttöoikeuden, kun kutsu suoritetaan ketjussa.5

Tämä ei ole sama asia kuin sanoa, että allekirjoitus itsessään jo siirsi tokenit. Sen vaikutus on luvan asettaminen, jos standardin ehdot täyttyvät ja kutsu toteutetaan. Luvan saanut osoite voi tämän jälkeen käyttää oikeutta tokenin toimintojen mukaisesti. Kuinka paljon ja millä ehdoin, riippuu kyseisestä luvasta ja toteutuksesta.5

Standardin viestissä on muun muassa omistaja, oikeuden saaja, määrä, nonce ja määräaika. Nonce on käytön yksilöivä arvo, jonka avulla standardi torjuu saman luvan uudelleenkäyttöä. Määräaika rajoittaa sitä, milloin permit voidaan toimittaa hyväksyttäväksi; se ei sellaisenaan tarkoita, että jo asetettu allowance päättyisi samana hetkenä.5

Tämä ero on helppo ohittaa. Jos näet vain lähiaikaan päättyvän määräajan, älä päättele siitä automaattisesti, että myös mahdollisesti syntyvä käyttöoikeus lakkaa silloin. Tarkista nimenomaan viestin ja sopimuksen ehdot. Sama sana voi eri tuotteissa viitata eri asiaan.

Siirtovaltuutus on eri asia kuin allowance

EIP-3009 kuvaa toisenlaisen valtuutusmallin: allekirjoitettuihin tietoihin voidaan sisällyttää lähettäjä, vastaanottaja, määrä, voimassaoloaika ja yksilöivä nonce, minkä perusteella sopimuksen toiminto voi toteuttaa siirron.6 Tämä on eri mekanismi kuin ERC-2612:n allowance-lupa, vaikka palvelun käyttöliittymä käyttäisi molemmista yleistä sanaa ”permit” tai ”authorization”.

Siksi ei riitä, että tunnistat yhden sanan lompakon pyynnössä. Kysy, onko kyse oikeudesta käyttää tokeneita myöhemmin vai tietyn siirron valtuutuksesta. Tarkista myös, käyttääkö kyseinen token ja palvelu juuri sitä standardia, jota ohje kuvaa. Kaikki tokenit eivät tue kumpaakaan, ja toteutuksissa voi olla eroja.

MetaMaskin yleinen käyttöoikeusopas käsittelee myös allekirjoituksiin perustuvia malleja, mutta yksittäisen viestin tekninen vaikutus on varmennettava kyseisen standardin ja sopimuksen perusteella.4, 5, 6 Yleinen opas ei korvaa sopimuksen kenttien tarkistamista.

Rakenteinen viesti ei ole turvallisuustakuu

EIP-712 määrittelee tavan esittää ja allekirjoittaa rakenteista tietoa. Tavoitteena on helpottaa viestin merkityksen näyttämistä verrattuna pelkkään vaikeasti tulkittavaan merkkijonoon. Standardi ei kuitenkaan itsessään lisää uudelleenkäyttösuojausta kaikkiin sovelluksiin.7

Rakenteinen näkymä voi siis auttaa, mutta sen ulkoasu ei todista, että pyyntö on turvallinen. Oikean näköinen sivu voi pyytää lupaa väärälle osoitteelle tai suuremmalle määrälle kuin käyttäjä tarkoitti. Tarkista myös sovelluksen verkko ja pyynnössä näkyvä sopimus, jos lompakko näyttää ne. Osoitteen nimi tai tunnus ei ole yksin varmistus vastaanottajan henkilöllisyydestä.

Jos lompakko näyttää tiedot puutteellisesti tai teknisessä muodossa, älä täydennä aukkoja omilla oletuksillasi. Tarkista palvelun dokumentaatiosta ja lompakon ohjeesta, miten juuri tämä pyyntö esitetään. Jos merkitystä ei saa selville, pyynnön voi jättää hyväksymättä.

Sovelluksen ja lompakon käyttämä sanasto voi myös poiketa toisistaan. Pyynnön otsikko voi olla yleinen, vaikka tarkemmat kentät kuvaisivat tiettyä valtuutusta. Jos lompakossa on mahdollista avata lisätiedot, tarkastele niitä ennen päätöstä. Teknisten kenttien näkyminen ei silti yksin todista, että niiden perusteella ymmärtää sopimuksen kaikki vaikutukset. Jos pyyntö on ristiriidassa tekemäsi tehtävän kanssa, älä kiirehdi hyväksymään sitä siksi, että sovellus sanoo vaiheen olevan välttämätön. Pyyntöön voi palata myöhemmin, kun olet selvittänyt, mitä kyseisellä allekirjoituksella on tarkoitus tehdä.

Määrä, määräaika ja valtuutettu erikseen

Ennen hyväksyntää kannattaa käydä pyynnön yksittäiset kentät läpi yksi kerrallaan. Token kertoo, mitä omaisuutta viesti koskee. Määrä kertoo, millaisesta rajasta tai siirtomäärästä viestissä puhutaan. Saajaa kuvaava osoite puolestaan kertoo, kenen hyväksi oikeus tai suoritus on tarkoitettu. Näitä ei pidä sekoittaa palvelun etusivulla näkyvään nimeen: allekirjoituksen sisältö ratkaisee yhdessä sitä käsittelevän sopimuksen kanssa.

Jos määrä on esitetty poikkeuksellisen suurena, selvitä, tarkoittaako se laajaa käyttöoikeutta. Myös oikean palvelun pyytämä laaja lupa kasvattaa sitä määrää, jonka käyttö voi olla luvan piirissä. Pyynnön tarpeellisuus ja mahdollisuus muuttaa määrää riippuvat tuotteesta. Älä oleta, että jokaisessa lompakossa on samanlainen asetuksen nimi tai että käyttöliittymän tekemä ehdotus olisi sinun tilanteeseesi sopiva.4

Aikaleimoja tarkastellessa kysy lisäksi, minkä vaiheen voimassaolosta on kyse. EIP-2612:n määräaika liittyy permit-kutsun hyväksymiseen, kun taas EIP-3009:n valtuutuksessa on erikseen voimassaolon alkua ja loppua koskevat kentät.5, 6 Nämä eivät ole yleisiä lupauksia kaikista allekirjoitusjärjestelmistä. Jos näyttö ei kerro, mitä aikaraja tekee, asia on selvitettävä sovelluskohtaisesti.

Milloin pyyntöä on syytä epäillä?

Vertaa pyyntöä siihen tehtävään, jota olit tekemässä. Jos tarkoituksena oli lukea palvelun julkista sisältöä, pyyntö myöntää tokenien käyttöoikeus tarvitsee erityisen hyvän selityksen. Samoin kiirehtivä viesti, joka käskee hyväksymään jotakin heti tilin suojaamiseksi, ei korvaa pyynnön sisällön tarkistamista. Avaa palvelun ohje erikseen tuntemasi osoitteen kautta sen sijaan, että nojaisit pelkkään viestin väitteeseen.

Jos allekirjoituspyyntö näyttää tutulta, mutta saajan osoite tai token ei vastaa sitä, mitä odotit, keskeytä ja tarkista tiedot riippumattomasta lähteestä. Väärä merkki osoitteessa tai eri verkko voi muuttaa koko tapahtuman tarkoituksen. Älä kuitenkaan pidä visuaalista täsmäämistä täydellisenä turvallisuustarkastuksena: sopimuksen toimintaa ei voi arvioida pelkän nimen perusteella.

Lompakon palautuslausetta tai yksityistä avainta ei tarvita tavallisen viestin allekirjoittamiseen verkkosivulle kirjoitettuna. Älä syötä niitä palvelun lomakkeeseen tai luovuta niitä tukena esiintyvälle henkilölle. Allekirjoituspyynnön ymmärtäminen on eri asia kuin avaimen antaminen toiselle.

Kuvitteellinen esimerkki

Kuvitellaan, että käyttäjä avaa sovelluksen, joka lupaa näyttää tilin tiedot ilman maksua. Lompakko näyttää allekirjoituspyynnön, jossa esiintyy ERC-2612-tyyppinen permit, tokenin nimi, käyttöoikeuden saaja ja määrä. Sovelluksen sivu puhuu kirjautumisesta, mutta pyynnön sisältö kuvaa luvan antamista.

Käyttäjä ei hyväksy pyyntöä vielä. Hän vertaa näkyvää saajaa ja määrää palvelun dokumentaatioon ja tarkistaa, miksi pelkkään tietojen katseluun tarvittaisiin tällainen oikeus. Koska selitystä ei löydy, hän sulkee pyynnön. Esimerkki ei väitä, että jokainen permit olisi huijaus: ristiriita tarkoituksen ja pyydetyn valtuutuksen välillä on syy selvittää asia ennen allekirjoitusta.

Tarkistuslista ennen allekirjoitusta

• Tarkoitus: Mitä olit tekemässä, ja selittääkö palvelu, miksi se tarvitsee juuri tämän viestin?
• Tyyppi: Onko viesti kirjautumista, käyttöoikeutta, siirtovaltuutusta vai jotakin muuta varten? Pelkkä otsikko ei välttämättä riitä.
• Oikeuden saaja tai vastaanottaja: Mikä osoite näkyy pyynnössä, ja onko sen yhteys käyttämääsi palveluun mahdollista tarkistaa?
• Määrä: Kuinka paljon tokeneita valtuutus koskee? Jos määrä näyttää suuremmalta kuin tarvitset, selvitä miksi ennen hyväksymistä.
• Aika ja yksilöinti: Mitä määräaika rajoittaa ja näkyykö viestissä nonce? Niiden merkitys riippuu viestin tyypistä.
• Verkko ja sopimus: Vastaavatko lompakon näyttämät tiedot sitä verkkoa ja sovellusta, jota tarkoitit käyttää?

Kaikki tiedot eivät näy kaikissa lompakoissa samalla tavalla. Listaa ei myöskään voi käyttää mekaanisena takuuna: vaikka kentät näyttäisivät tutuilta, sopimuksen toiminta voi olla toinen kuin oletat. Tarvittaessa tarkista tuotteen ajantasainen dokumentaatio ennen kuin jatkat.

Jos allekirjoitit epäilyttävän pyynnön

Lopeta uusien pyyntöjen hyväksyminen ja selvitä, mitä allekirjoitit. Tallenna palvelun osoite, pyynnön tiedot ja mahdolliset tapahtumatiedot ilman että jaat palautuslausetta tai yksityisiä avaimia. Jos kyse on taloudellisesta vahingosta tai petosepäilystä, ota yhteys käyttämäsi palvelun tukeen ja tee tarvittaessa rikosilmoitus poliisille.

Allekirjoituksen mitätöinti, jo asetetun käyttöoikeuden muuttaminen ja varojen siirto ovat eri asioita. Käytettävissä olevat toimet riippuvat viestistä, sopimuksesta ja siitä, onko valtuutus jo käytetty. Pelkkä sovelluksen sulkeminen ei välttämättä poista annettua allekirjoitusta. Älä luota tuntemattomaan yhteydenottoon, joka lupaa varmasti palauttaa varat.

Paras hetki ymmärtää allekirjoituksen vaikutus on ennen hyväksyntää. Kaasumaksun puuttuminen on yksi käyttöliittymän tieto, ei vastaus siihen, minkä oikeuden olet antamassa.