The AUTH0 byte dictates at which memory page password protection begins to apply to all subsoquent memory pages. The default value of AUTH0 is FF, which effectively leaves all pages unprotected by the password feature. Both the Dangerous NFC app and our pre-programming of the NExT sets AUTH0 to E2, which leaves the user memory pages unprotected by the password (and fully writable).
Within the CFG byte there is a PROT bit… the PROT bit defines the PROTECTION scheme used by the password feature. Leaving PROT set to 0 means that the password feature only protects pages defined by AUTH0 against unauthenticated writes… in effect, you must authenticate your session with the correct password before you can write to any protected pages. This includes configuration pages and the PASSWORD bytes in page E5. As you can see, this means if you set AUTH0 to FF or any page value after E5, anyone could write new PWD bytes without first having to authenticate. This is not good, so we protect all configuration bytes by default. If you set PROT to 1 then you must authenticate with the password first before you can read or write any pages protected by AUTH0.
Just one other oddity to point out… the UID of the NTAG216 chip is stored in the first couple memory pages, however if you set PROT to 1 and AUTH0 to the first page 01, this does not mean you are effectively making it impossible to read the tag UID without first authenticating. The UID is communicated during the ISO14443A announcement and selection process, so even though the UID is stored in the first couple pages, you cannot password protect the UID from being read.