Crypter un champ numérique

Salut à tous,

Est-ce qu'il possible de crypter un champ numérique pour avoir une valeur également numérique et ayant la même longueur ?

Cas d'utilisation : pour ne pas stocker un numéro de carte bancaire dans la base (ou du moins le stocker crypté) !!

Si oui, pouvez-vous me filer la commande ou le bout de code qui fait ça ?

Mercii :)

Tu veux pouvoir le décrypter ?

Je n'ai pas une connaissance très élevée en cryptologie Oracle (package sys.dbms_obfuscation_toolkit), mais je ne pense pas que ce soit possible.

En cherchant un peu sur le net, https://www.pcisecuritystandards.org...0#pci_dss_v2-0 normalement faut utiliser une vraie cryptographie (donc pas rester sur du NUMBER)

A part ça.. en parlant uniquement au niveau SQL, tu peux remplacer chaque chiffre par un autre (ça ne résistera pas à un hack).

Code:

---

1 2 3 4

SELECT cb, TRANSLATE(cb, '0123456789','6543219870') crypte, TRANSLATE( TRANSLATE(cb, '0123456789','6543219870'), '6543219870', '0123456789') decrypte FROM ( SELECT TRUNC(DBMS_RANDOM.VALUE(1000000000000000,9999999999999999)) cb FROM dual connect BY LEVEL < 10)

---

Tu peux aussi le faire chiffre à chiffre (une fonction différente par position), garder une position (exemple la 8ème) et faire une fonction différente suivant ce chiffre, etc...

Il existe un nouveau package, DBMS_CRYPTO, qui pourrait peut-être répondre à ton besoin.
https://docs.oracle.com/cd/B19306_01...o.htm#i1004143
"DBMS_CRYPTO is intended to replace the DBMS_OBFUSCATION_TOOLKIT, providing greater ease of use and support for a range of algorithms to accommodate new and existing systems."

En revanche je suis surpris par ce passage car j'ai l'impression que les NUMBER ne sont pas pris en compte:

Code:

---

1 2 3 4 5 6 7 8 9

Table 24-2 DBMS_CRYPTO Datatypes Type Description BLOB A source or destination binary LOB   CLOB A source or destination character LOB (excluding NCLOB)   PLS_INTEGER Specifies a cryptographic algorithm type (used with BLOB, CLOB, and RAW datatypes)   RAW A source or destination RAW buffer

---

Autre info : est-ce que ton champ NUMBER rentre dans la case PLS_INTEGER? Si oui, OK, sinon... voir plus bas la partie VARCHAR2.

Code:

---

PLS_INTEGER is a PL/SQL data type used for storing signed integers. PLS_INTEGER is defined in the STANDARD package as a subtype (or rather a synonym) of BINARY_INTEGER. Variables declared as PLS_INTEGER can be assigned values between -2**31 to 2**31-1 (-2,147,483,648 to 2,147,483,647).

---

Les VARCHAR2 peuvent être utilisés si convertis au préalable en RAW avec UTL_I18N.STRING_TO_RAW. Si les NUMBER ne sont pas pris en compte, il faudra peut-être les convertir d'abord en VARCHAR2 puis en RAW?

Code:

---

1 2

Restrictions The VARCHAR2 datatype is not directly supported by DBMS_CRYPTO. Before you can perform cryptographic operations on data of the type VARCHAR2, you must convert it to the uniform database character set AL32UTF8, and then convert it to the RAW datatype. After performing these conversions, you can then encrypt it with the DBMS_CRYPTO package.

---

En soi, un numéro de carte bancaire (pas plus qu'un numéro de sécurité sociale) n'est pas un nombre.
C'est un identifiant composé d'une série de chiffres, aucunement une quantité sur laquelle on peut faire des calculs.
Il n'y a rien qui empêche de le stocker dans un VARCHAR.

Tu as parfaitement raison, mon prof d'admin Oracle disait qu'on ne met en NUMBER que le schamps sur lesquels on doit faire des opérations mathématiques, donc pas les numéros de téléphone, pas les CB, pas le N° INSEE...

Salut,

J'ai réussi à obtenir le résultat que je voulais via des requêtes PL/SQL :

Code:

---

1 2	SELECT utl_raw.bit_xor('1234123412341234', '1000100010001000') FROM dual;

---

>> Valeur retournée : 0234023402340234

Code:

---

1 2	SELECT utl_raw.bit_xor('0234023402340234', '1000100010001000') FROM dual;

---

>> Valeur retournée : 1234123412341234

Le souci est que lorsque je veux mettre tout ça dans une fonction PL/SQL, elle me retourne des valeurs différentes !! Je suppose que c'est dû au fait que la fonction utl_raw.bit_xor accepte des RAW en entrée (et non pas des VARCHAR2)...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

SELECT UTL_RAW.CAST_TO_RAW('1234123412341234') INTO num_carte_raw FROM dual;   SELECT UTL_RAW.CAST_TO_RAW('1000100010001000') INTO mask_raw FROM dual;   SELECT UTL_RAW.BIT_XOR(num_carte_raw, mask_raw) INTO v_result_raw FROM dual;   SELECT UTL_RAW.CAST_TO_VARCHAR2(v_result_raw) INTO num_carte_xor FROM dual;

---

>> La valeur retournée est :
000100010001000 (au lieu de 0234023402340234)

Est-ce qu'il y a moyen de récupérer le même résultat que les requêtes ?

Le souci c'est que dans

Code:

---

SELECT utl_raw.bit_xor('1234123412341234', '1000100010001000') FROM dual;

---

Oracle considère que '1234123412341234' est un RAW (valeurs hexa 12 34 12 34 12 34 12 34 12 34)
Donc il faut que tu transformes ta chaine '1234123412341234' non pas en cast_to_raw ('1' = ascii(49) = #31h), mais directement avec HEXTORAW

Voici un exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

DECLARE v_mask RAW(8) := HEXTORAW('1000100010001000'); v_numcarte VARCHAR2(16) := '1234123412341234'; v_numcrypt VARCHAR2(16); v_crypt RAW(8); BEGIN v_crypt := UTL_RAW.bit_xor(v_mask, HEXTORAW(v_numcarte)); v_numcrypt := RAWTOHEX(v_crypt); DBMS_OUTPUT.PUT_LINE('Crypt Char:'|| v_crypt); v_crypt := UTL_RAW.bit_xor(v_mask, HEXTORAW(v_numcrypt)); v_numcrypt := RAWTOHEX(v_crypt); DBMS_OUTPUT.PUT_LINE('Decrypt Char:'|| v_numcrypt); END;

---

Résultat

Code:

---

1 2	Crypt Char:0234023402340234 Decrypt Char:1234123412341234

---

Merci beaucoup :P
C'est bien le bout de code que je recherchais