Online-invoice: A TokenExchangeRequest hívás INVALID_REQUEST_SIGNATURE hibát ad vissza

[vajayattila]

Helló!

Az iránt érdeklődöm, hogy a 2.0-ás teszt környezet működőképes-e?
Feltételez-e új felhasználói regisztrációt a 2.0-ás API a teszt környezet használatához.
Történt-e módszertani változás az adatok aláírásában az 1.1-es verzióhoz képest (ha igen ennek leírását hol találom meg)?

Jelen pillanatban a TokenExchangeRequest hívás INVALID_REQUEST_SIGNATURE hibával tér vissza az általam beadott adatokkal.

Előre is köszönöm a segítséget.

[NTCA-developer]

Szia @vajayattila

Nem kell külön regisztráció a 2.0 használatához és a teszt környezet is működik, azonban a requestSignature számítása változott. A konkrét kérdésre a választ a 2.0-ás interfész dokumentáció 1.5.2 pontja tartalmazza, azonban ha ez új, akkor javasolom hogy nézd át az 5.3-as fejezetet is, ahol dióhéjban összegezve vannak az 1.1 -> 2.0 módosítások.

[vajayattila]

Köszi az infót.

A dokumentumnak megfelelően összerakom a requestSignature értékét. Igazából annyit csináltam, hogy a sha-512 metódust lecseréltem sha3-512-re. CryptoPP 8.2-t használok.

/*Régi metódus*/
extern "C" __declspec(dllexport)
long __stdcall Sha512Hex(const char* in, char** out, unsigned int *size) {
    long retval = ERR_OK;
    SHA512 hash;
    string digest;

    StringSource s(
        in, true, new HashFilter(
            hash, new HexEncoder(new StringSink(digest))
        )
    );

    *size = digest.length() + 1;
    *out = new char[*size];
    if (*out != NULL) {
        memset(*out, 0, *size);
        strcpy(*out, digest.c_str());
    }
    else {
        retval = ERR_MEM_ERROR;
    }

    return retval;
}

/*Új metódus*/
extern "C" __declspec(dllexport)
long __stdcall Sha3512Hex(const char* in, char** out, unsigned int *size) {
    long retval = ERR_OK;
    SHA3_512 hash;
    string digest;

    StringSource s(
        in, true, new HashFilter(
            hash, new HexEncoder(new StringSink(digest))
        )
    );

    *size = digest.length() + 1;
    *out = new char[*size];
    if (*out != NULL) {
        memset(*out, 0, *size);
        strcpy(*out, digest.c_str());
    }
    else {
        retval = ERR_MEM_ERROR;
    }

    return retval;
}

A kapott sha3-512 értéket ellenőriztem egy online tool segítségével. Ugyanazt a hash értéket kaptam vissza. A TokenExchangeRequest ezúttal INVALID_SECURITY_USER hibát ad. A user adatok biztos, hogy jók, mert ugyanezeket adva át a 1.1-es verziójú szolgáltatásnak, rendben visszajön.
Van valami ötlet mit szúrhatok el?

[vajayattila]

Lehet esetleg, hogy a password hash nem jó?
A passwordHash nem sha3-512?
Ezt írjátok a doksiban: passwordHash Sha512HashType [0-9A-F]{128}
but why?

[vajayattila]

Egyébként ez volt a baj. Azt mondjuk nem értem itt miért nem cseréltétek le a hash eljárást, de elfogadom, hogy így van. A kérdés csak az, így is marad?

[NTCA-developer]

Szia!

Örülök hogy az INVALID_REQUEST_SIGNATURE hibán túljutottál. Annak kevésbé, hogy nem volt egyértelmű a doksiból, hogy a passwordHash nem változik, mert még itt is tett a közösség a doksi ilyen irányú egyértelműsítésére vonatkozó javaslatokat. De majd még ötletelek, mit lehetne tenni. Esetleg ötlet, hol kellene ezt jobban kihangsúlyozni?

Kérdésedre válaszul hogy a passwordHash miért nem változik, 2 dolgot tudok mondani. Mindkettő indokról is írtam már korábban, egyszer egy dev diary-ban, egyszer pedig itt egy konkrét ticket kapcsán.

• A jelszavak biztonságos tárolásának vagy egy NIST-es és egy OWASP-os irányelve is és mi mindkettőt betartjuk. Ennek egyenes következménye, hogy hash algoritmust nem cserélhetsz önmagában, csakis a jelszavakkal együtt. (ezzel feltettünk cc 300.000 technikai usert a mérleg egyik serpenyőjébe)
• A requestSignature esetén nem főként az SHA2 algoritmussal van a baj, hanem a crc32-vel. A rendszer gazdasági életbe belépésekor tudatosan döntöttünk úgy, hogy nem a legmagasabbra tesszük a lécet, mivel csomó legacy nyelven írt számlázóprogram működik még ma is, és nekik könnyebb 2 lépcsőben, megfelelő időkerettel ezt megugrani, mint mindent a bevezetéssel egyidőben.

Mivel a mérleg két serpenyője úgy áll, hogy a másik oldalon maximum csak az egységesség áll mind benefit, ezért úgy gondoltuk hogy most nem cseréltetünk jelszót csak ezért. Amire sérülékeny az SHA2, annak egy jelszóhash esetében 0 relevanciája van. Persze ez nem azt jelenti, hogy a későbbiekben bármi miatt nem kell majd a technikai userek jelszavát cserélni/megújítani, de ez majd egy másik beszélgetés lesz.

Lezárod majd?

[vajayattila]

Igazad van, a doksi alapján egyértelmű, hogy passwordHash hash eljárása megegyezik az 1.1 verziójú szolgáltatáséval. Én gondoltam túl a dolgot, hogy felesleges többféle hash eljárást alkalmazni.

Az, hogy a felhasználónak jelszót kell kötelezően módosítania, ezt az érvet nem tudom elfogadni. Az ügyfélkapu időközönként szívja a vérem, hogy változtassak jelszót, de ne adjam meg az előzőt stb. Ezt nem 300 ezer emberrel játssza el, hanem mindegy ügyfélkapus felhasználóval.

A második érved a technológia váltásról félig el tudom fogadni, félig nem. Az én magánvéleményem az, hogy az ember mindenképpen belekényszerül egy váltásba, akkor az olyan váltás legyen, ami hosszú távra szól, különben kétszer kell dolgoznia vele.

Részemről a jegyet lezárhatod.

Köszönöm szépen a segítséget.

[NTCA-developer]

Csak még egy gondolat.

Szerintem összemosod a két dolgot. Azzal semmi baj sincs ha az Ügyfélkapu jelszócserére kötelez, de ezt abból az okból teszi, mert a jelszó már túl régi, nem pedig azért, mert neki a jelszó új hash alakjára van szüksége. Ez szerintem eléggé nagy különbség.

[vajayattila]

Szerintem a felhasználó szemszögéből nincs különbség. Mindkettő olyan folyamat, amire nem kérte meg a szolgáltatás üzemeltetőjét, de valami miatt (biztonsági okok, fejlesztési okok miatt) rákényszerül.

Nem véletlenül kérdeztem meg, hogy a 2.0-ához kell-e új felhasználót létrehozni. Simán el tudom képzelni, hogy a 1.1 és 2.0 felhasználói bázisa nem azonos. Így a 2.0-ás fejlesztései nem vágja tacsra a 1.1 működését. Egy másik megoldás, hogy felveszel a felhasználó törzsbe egy 2.0 jelszó mezőt. Biztos van más megoldás is, de nekem ez jutott hirtelen eszembe.