Oracle SQL 将触发器插入 Hash 密码无效（CHAR 问题）

Question

I'm trying to build a insert trigger to hash a string into a SH-256 password:

DROP TABLE client;

CREATE TABLE client (
    id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    password CHAR(64) NOT NULL
);


-- Add Insert Trigger
CREATE OR REPLACE TRIGGER client_hash_trigger
    BEFORE INSERT
    ON client
    FOR EACH ROW
DECLARE 
    password_hash CHAR(64);
BEGIN
    SELECT STANDARD_HASH(:NEW.password, 'SHA256') INTO password_hash FROM dual;
    :NEW.password := password_hash;
END;


INSERT INTO client VALUES (DEFAULT, 'BruteForce');

When I run the SQL I'll get a wrong hash in my table. When I change booth char to varchar it's working. When I put the STANDARD_HASH directly into the insert line it working as well. Where is the issue?

Answer 1

You use a char column to store a RAW value, returned by standard_hash ; you should cast your RAW to a different type, for example by UTL_RAW procedures.

Also, consider that when you define a column as char(64) you mean that all the values will be 64 characters long, so 'BruteForce' will be padded to 64 characters and the hash will be computed on the padded string.

If you try to add something like

dbms_output.put_line('Password is: "' || :NEW.password || '"');

to your trigger, you will see:

Password is: "BruteForce                                                      "

Varchar2 , differently will only use the characters you need, so the hash would be computed exactly on 'BruteForce' , that's why if you switch to varchar2 you see a different hash result.

If you write something like

INSERT INTO client VALUES (DEFAULT, STANDARD_HASH('BruteForce', 'SHA256'));

the hash is computed not on che column content (which is a char(64) , thus being 64 characters long), but over the string 'BruteForce' and the resulting hash in casted into char(64) . What Oracle does is:

1. compute the hash
2. cast it to char(64)

The issue with the padding comes when you use the trigger because the trigger is based on the table structure, so :NEW.password is a char(64) value and the hash is computed over the already casted value, so over a string made by 64 characters. What happens with the trigger is

1. cast the string to char(64) , because you are inserting in a char(64) column, thus padding
2. compute the hash

Answer 2

[TL;DR] Use STANDARD_HASH( RTRIM(:new.PASSWORD ), 'SHA256' ) as you want to generate the password on 'BruteForce' and not 'BruteForce ' (etc.) padded with white-space to a length of 64 characters (which is what using CHAR(64) would give you).

---

If you don't want to use a salt (which you should be using in this day-and-age) then just right-trim the password to get rid of the trailing white-space that the CHAR data type have padded the string with:

CREATE OR REPLACE TRIGGER client_hash_trigger
BEFORE INSERT ON client
FOR EACH ROW
BEGIN
  SELECT STANDARD_HASH( RTRIM( :new.PASSWORD ), 'SHA256' )
  INTO   :new.PASSWORD
  FROM   DUAL;
END;
/

Then:

CREATE TABLE client (
    id            NUMBER(10,0)
                  GENERATED ALWAYS AS IDENTITY
                  CONSTRAINT client__id__pk PRIMARY KEY,
    password      CHAR(64)
                  NOT NULL
);

INSERT INTO client (id, password) VALUES (DEFAULT, 'BruteForce');

Will output:

SELECT id, password FROM client;

 ID | PASSWORD -: |:--------------------------------------------------------------- 1 | 6BAFE79E0E7360094A490C0B84F2D5BA1C5A6E5C6FE1E45C2E7850966698AF29 

---

Hashing and Salting

Adapted from this answer

If you also want to follow best practice, then you should salt the password before hashing:

CREATE TABLE client (
    id            NUMBER(10,0)
                  GENERATED ALWAYS AS IDENTITY
                  CONSTRAINT client__id__pk PRIMARY KEY,
    password      CHAR(64)
                  NOT NULL,
    password_salt VARCHAR2(61)
                  NOT NULL
);

Then your trigger is:

CREATE TRIGGER client_hash_trigger
BEFORE INSERT OR UPDATE ON client
FOR EACH ROW
BEGIN
  IF :new.PASSWORD = :old.PASSWORD THEN
    -- Assume things haven't changed (The chances of a hash collision are vanishingly small).
    -- Make sure the old salt is not replaced if the password hash hasn't changed.
    :new.PASSWORD_SALT := :old.PASSWORD_SALT;
  ELSE
    -- Regenerate a new salt and hash the password.
    :new.PASSWORD_SALT := DBMS_RANDOM.STRING( 'P', FLOOR( DBMS_RANDOM.VALUE( 40, 61 ) ) );
    SELECT STANDARD_HASH ( :new.PASSWORD_SALT || RTRIM( :new.PASSWORD ), 'SHA256' )
    INTO   :new.PASSWORD
    FROM   DUAL;
  END IF;
END;
/

And then:

INSERT INTO client (id, password) VALUES (DEFAULT, 'BruteForce');

May output:

SELECT * FROM client;

 ID | PASSWORD | PASSWORD_SALT -: |:--------------------------------------------------------------- |:------------------------------------------ 1 |  7465541FDF9379B2112D4E92150F594732139E94B79D0EB0247593B4E8CEB3E4 |  dhj4GOC8E(xA&8b9f)j@"Y- o$G.UECR\go.SrFaZ<& 

db<>fiddle here

Answer 3

A slight change to MT0 's answer to remove the context switch in the trigger by using dbms_crypto instead of standard_hash .

CREATE OR REPLACE TRIGGER client_hash_trigger
BEFORE INSERT ON client
FOR EACH ROW
BEGIN
  :new.PASSWORD := rawtohex(dbms_crypto.hash(src => utl_raw.cast_to_raw(:new.PASSWORD),
                                             typ => dbms_crypto.hash_sh256));
END;
/