VPN ਦੀ ਗੁਪਤ ਕੁੰਜੀ ਉੱਤੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਅਸਲ ਵਿੱਚ ਕੀ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ

VPN ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਦਿਖਣ ਵਾਲਾ ਪ੍ਰੋਂਪਟ ਗ਼ਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ। ਇਹ VPN ਖਾਤੇ ਦਾ ਪਾਸਵਰਡ ਨਹੀਂ ਹੈ, ਟਨਲ ਦਾ ਪਾਸਵਰਡ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਦਾਖਲ ਕਰਨ ਨਾਲ ਇਹ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕਨੈਕਸ਼ਨ ਸੁਰੱਖਿਅਤ ਹੈ। ਇਹ ਗੁਪਤ ਕੁੰਜੀ ਦੀ ਇੱਕ ਸੰਭਾਲੀ ਪੇਸ਼ਕਾਰੀ ਖੋਲ੍ਹਦਾ ਹੈ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਕੁੰਜੀ ਸਮੱਗਰੀ ਪੜ੍ਹ ਸਕੇ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਵਰਤ ਸਕੇ। ਇਸ ਤੋਂ ਬਾਅਦ ਜੋ ਵੀ ਹੁੰਦਾ ਹੈ ਉਹ ਵੱਖਰਾ ਸਵਾਲ ਹੈ।

ਅਮਲ ਵਿੱਚ ਜਵਾਬ ਕਿਨਾਰਿਆਂ 'ਤੇ ਗ਼ਲਤ ਹੁੰਦਾ ਹੈ: ਲੋਕ ਮੰਨਦੇ ਹਨ ਕਿ ਪਾਸਫ਼੍ਰੇਜ਼ ਚੱਲ ਰਹੀ ਟਨਲ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਜਾਂ ਇਸ ਨੂੰ ਬਦਲਣ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਲੀਕ ਹੋਈ ਕੁੰਜੀ ਦੀ ਕਾਪੀ ਰੱਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਦੋਵੇਂ ਧਾਰਨਾਵਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਇਸ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਇੱਕ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਖੁੱਲ੍ਹਾ ਰਹਿ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਆਪਰੇਟਰ ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਸੰਭਾਲਿਆ ਗਿਆ ਹੈ।

ਇੱਕ ਸੰਵਾਦ, ਕਈ ਵੱਖਰੇ ਭੇਤ

ਗੁਪਤ ਕੁੰਜੀ ਦਾ ਪਾਸਫ਼੍ਰੇਜ਼ ਇੱਕ ਫਾਈਲ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਖਾਤਾ ਪਾਸਵਰਡ ਤੁਹਾਨੂੰ ਸੇਵਾ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। PKCS#12 ਆਯਾਤ ਪਾਸਵਰਡ ਉਸ ਬੰਡਲ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਅਤੇ ਉਸਦਾ ਸਰਟੀਫਿਕੇਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੁੰਜੀ ਦੇ ਆਪਣੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਵਰਗੀ ਹੀ ਸਤਰ ਨਾ ਹੋ ਸਕੇ। ਇਹ ਪ੍ਰੋਂਪਟ ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ ਦਿਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਕਿ ਕਿਹੜਾ ਭੇਤ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ, ਉਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕੁੰਜੀਆਂ ਗ਼ਲਤ ਖੇਤਰ ਵਿੱਚ ਚਿਪਕ ਜਾਂਦੀਆਂ ਹਨ।

ਟਨਲ ਦੀ ਆਪਣੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਚੌਥੀ ਚੀਜ਼ ਹੈ। ਡਾਟਾ ਚੈਨਲ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਗੱਲਬਾਤ ਕੀਤੀਆਂ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਵਰਤਦਾ ਹੈ; ਗੁਪਤ ਕੁੰਜੀ ਦੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਦਾ ਵੱਖਰੇ ਪੈਕਟਾਂ ਦੀ ਸੁਰੱਖਿਆ ਵਿੱਚ ਕੋਈ ਰੋਲ ਨਹੀਂ। ਜੇ ਕੋਈ ਕੁੰਜੀ ਫਾਈਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਪਾਸਫ਼੍ਰੇਜ਼ ਦਾ ਆਫ਼ਲਾਈਨ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਉਹ ਪੈਕਟ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਤਾਂ ਪਾਸਫ਼੍ਰੇਜ਼ ਬੇਮਤਲਬ ਹੈ।

ਡਿਸਕ 'ਤੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੀ ਕਵਰ ਕਰਦੀ ਹੈ

ਇਨਕ੍ਰਿਪਟ ਕੀਤੀ PEM ਕੁੰਜੀ ਦੋ ਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਹੈਡਰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ। ਆਧੁਨਿਕ PKCS#8 ਰੂਪ -----BEGIN ENCRYPTED PRIVATE KEY----- ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ; ਪੁਰਾਣਾ PEM ਰੂਪ, ਜੋ ਪੁਰਾਣੇ OpenVPN ਸੈਟਅੱਪਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਆਮ ਹੈ, -----BEGIN RSA PRIVATE KEY----- ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਸਦੇ ਠੀਕ ਹੇਠਾਂ Proc-Type: 4,ENCRYPTED ਅਤੇ DEK-Info ਲਾਈਨ ਰੱਖਦਾ ਹੈ। ਫਾਈਲ ਗੁਪਤ ਕੁੰਜੀ ਨੂੰ ਤੁਹਾਡੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਤੋਂ ਲਏ ਕੁੰਜੀ ਹੇਠ ਇਨਕ੍ਰਿਪਟ ਕਰਕੇ ਰੱਖਦੀ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਿਤ ਦੁਹਰਾਅ ਸੰਖਿਆ ਜਾਂ ਕੰਮ ਦੇ ਕਾਰਕ ਵਾਲੇ ਪਾਸਵਰਡ-ਆਧਾਰਿਤ KDF ਰਾਹੀਂ। OpenSSL pkey ਦਸਤਾਵੇਜ਼ ਰੂਪਾਂ ਅਤੇ ਪੜ੍ਹਦੇ ਸਮੇਂ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਵਿਕਲਪਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ।

ਇਸ ਤੋਂ ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਕਮਜ਼ੋਰ ਪਾਸਫ਼੍ਰੇਜ਼ 'ਤੇ KDF ਜਿੰਨੀ ਤੇਜ਼ੀ ਦਿੰਦਾ ਹੈ ਉੱਨੀ ਤੇਜ਼ੀ ਨਾਲ ਆਫ਼ਲਾਈਨ ਹਮਲਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਫਾਈਲ ਇਜਾਜ਼ਤਾਂ ਅਤੇ ਬੈਕਅੱਪ ਤੱਕ ਪਹੁੰਚ ਫਾਈਲ ਇਨਕ੍ਰਿਪਟ ਹੋਣ 'ਤੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਰਹਿੰਦੀ ਹੈ। ਅਤੇ ਜੋ ਹਮਲਾਵਰ ਪਾਸਫ਼੍ਰੇਜ਼ ਤੋਂ ਬਿਨਾਂ ਸਿਰਫ਼ ਫਾਈਲ ਲੈਂਦਾ ਹੈ ਉਸਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ; ਜੋ ਫਾਈਲ ਅਤੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਦੋਵੇਂ ਲੈਂਦਾ ਹੈ ਉਸ ਕੋਲ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ, ਜਿਵੇਂ ਇਹ ਕਦੇ ਇਨਕ੍ਰਿਪਟ ਹੀ ਨਾ ਹੋਈ ਹੋਵੇ।

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 ਹੈਡਰ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀ ਫਾਈਲ ਵਿੱਚ ਇਨਕ੍ਰਿਪਸ਼ਨ ਸਾਬਤ ਕਰਨ ਵਾਲੀਆਂ Proc-Type ਅਤੇ DEK-Info ਲਾਈਨਾਂ ਦਿਖਾਉਂਦਾ ਹੈ; ਇੱਕਲੀ ਇੱਕ ਲਾਈਨ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਸਬੂਤ ਨਹੀਂ। pkey ਲਾਈਨ ਪਾਸਫ਼੍ਰੇਜ਼ ਮੰਗਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਜਨਤਕ ਅੱਧਾ ਛਾਪਦੀ ਹੈ, ਜੋ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਫਾਈਲ ਅਤੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਕੰਮ ਕਰਦੇ ਹਨ ਗੁਪਤ ਕੁੰਜੀ ਨੂੰ ਬੇਪਰਦ ਕੀਤੇ ਬਿਨਾਂ। ਉਸ ਜਾਂਚ ਲਈ -text ਨਾ ਵਰਤੋ: ਇਹ ਗੁਪਤ ਹਿੱਸੇ, privateExponent, prime1, prime2 ਅਤੇ ਬਾਕੀ ਛਾਪਦੀ ਹੈ, ਅਤੇ ਉਹ ਆਉਟਪੁੱਟ ਕਦੇ ਵੀ ਕਿਤੇ ਚਿਪਕਾਈ ਨਹੀਂ ਜਾਣੀ ਚਾਹੀਦੀ, ਨਾ ਟਿਕਟ ਵਿੱਚ, ਨਾ ਚੈਟ ਵਿੱਚ, ਨਾ ਲੌਗ ਵਿੱਚ। PKCS#12 ਕਮਾਂਡ ਇਹ ਵੀ ਦੱਸਦੀ ਹੈ ਕਿ ਬੰਡਲ ਵਿੱਚ ਵੱਖਰਾ MAC ਜਾਂ ਇਨਕ੍ਰਿਪਸ਼ਨ ਪਾਸਵਰਡ ਹੈ ਜਾਂ ਨਹੀਂ, ਜੋ ਸਹਿਕਰਮੀ ਨੂੰ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣਨਾ ਚੰਗਾ ਹੈ।

ਕੁੰਜੀ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਹ ਕੀ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ

ਖੋਲ੍ਹਣਾ ਉਸ ਪ੍ਰਕਿਰਿਆ ਲਈ ਇੱਕ-ਤਰਫ਼ਾ ਘਟਨਾ ਹੈ। ਕਲਾਇੰਟ KDF ਤੋਂ ਕੁੰਜੀ ਮੰਗਦਾ ਹੈ, ਫਾਈਲ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਿੰਨੀ ਦੇਰ ਲੋੜ ਹੋਵੇ ਗੁਪਤ ਕੁੰਜੀ ਨੂੰ ਮੈਮਰੀ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਉਸ ਪਲ ਤੋਂ ਪਾਸਫ਼੍ਰੇਜ਼ ਚੱਲ ਰਹੇ ਸੈਸ਼ਨ ਬਾਰੇ ਕੁਝ ਵੀ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰਦਾ: ਪ੍ਰਕਿਰਿਆ ਮੈਮਰੀ ਨਹੀਂ, ਕੋਰ ਡੰਪ ਨਹੀਂ, ਕਲਾਇੰਟ ਨਾਲ ਜੁੜਿਆ ਡੀਬੱਗਿੰਗ ਸੈਸ਼ਨ ਨਹੀਂ, ਅਤੇ ਕੁੰਜੀ ਵਰਤੋਂ ਵਿੱਚ ਹੋਣ ਵੇਲੇ ਲਿਆ ਮਸ਼ੀਨ ਦਾ ਬੈਕਅੱਪ ਨਹੀਂ।

ਇਹ ਪਾਸਫ਼੍ਰੇਜ਼ ਵਾਲੀ SSH ਕੁੰਜੀ ਜਾਂ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਦੀ ਖੁੱਲ੍ਹੀ ਤਿਜੋਰੀ ਵਰਗੀ ਹੀ ਸੀਮਾ ਹੈ। ਇਹ ਆਰਾਮ ਵਿੱਚ ਰਹਿੰਦੀ ਫਾਈਲ ਚੋਰੀ ਕਰਨ ਦੀ ਲਾਗਤ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਚੱਲਦੇ ਮਾਲਵੇਅਰ, ਕਲਾਇੰਟ ਨੂੰ ਦਸਤਖ਼ਤ ਕਰਨ ਲਈ ਕਹਿਣ ਵਾਲੀ ਅਧਿਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ, ਜਾਂ ਮੈਮਰੀ ਪੜ੍ਹ ਸਕਣ ਵਾਲੇ ਪ੍ਰਬੰਧਕ ਵਿਰੁੱਧ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਇਸਨੂੰ ਇੱਕ ਪਰਤ ਮੰਨੋ, ਕੁੰਜੀ ਨੂੰ ਆਸੇ-ਪਾਸੇ ਛੱਡਣਾ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਵਾਲੇ ਨਿਯੰਤਰਣ ਵਜੋਂ ਨਹੀਂ।

ਪ੍ਰੋਂਪਟ ਕਿਉਂ ਵਾਰ-ਵਾਰ ਵਾਪਸ ਆਉਂਦਾ ਹੈ

ਹਰ ਮੁੜ-ਕਨੈਕਸ਼ਨ 'ਤੇ ਦੁਬਾਰਾ ਪੁੱਛਣ ਵਾਲਾ ਕਲਾਇੰਟ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਖਰਾਬ ਹੋਵੇ। ਕੁਝ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਲਈ ਪਾਸਫ਼੍ਰੇਜ਼ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਕੁਝ ਇਸਨੂੰ OS ਕੀਚੇਨ ਵਿੱਚ ਸੰਭਾਲਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਨੂੰ ਇਸਨੂੰ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਸਹਾਇਕ ਵੱਲ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਵਿਵਹਾਰ ਮਿਲਦਾ ਹੈ ਉਹ ਕਲਾਇੰਟ ਅਤੇ ਉਸਦੀ ਸੰਰਚਨਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਕੁੰਜੀ ਫਾਈਲ 'ਤੇ ਨਹੀਂ।

ਜੇ ਦੁਹਰਾਉਂਦਾ ਪ੍ਰੋਂਪਟ ਹੀ ਅਸਲ ਸ਼ਿਕਾਇਤ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਤੋਂ ਇਨਕ੍ਰਿਪਸ਼ਨ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦੇ ਕੈਸ਼ਿੰਗ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਕਲਪ ਜਾਂਚੋ। ਪਾਸਫ਼੍ਰੇਜ਼ ਹਟਾਉਣ ਨਾਲ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਸਾਦਾ ਟੈਕਸਟ ਕੁੰਜੀ ਬਣ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਸ਼ਾਂਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਹੋਏ ਇੱਕੋ-ਇੱਕ ਆਰਾਮ ਨਿਯੰਤਰਣ ਦੀ ਕੀਮਤ 'ਤੇ। ਵਧੇਰੇ ਵਧੀਆ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸਟੋਰ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹੀ ਫਾਈਲ ਇਜਾਜ਼ਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਵਰਤਦੇ।

ਨੁਕਸਾਨ ਅਤੇ ਖੁਲਾਸਾ ਇੱਕੋ ਮੁਰੰਮਤ ਨਹੀਂ ਹਨ

ਗੁੰਮਿਆ ਪਾਸਫ਼੍ਰੇਜ਼ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਮੁੜ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਸਰਟੀਫਿਕੇਟ ਜਨਤਕ ਸਮੱਗਰੀ ਹੈ ਜੋ ਨਾਮ ਨੂੰ ਕੁੰਜੀ ਨਾਲ ਬੰਨ੍ਹਦੀ ਹੈ; ਇਸ ਵਿੱਚ ਗੁਪਤ ਕੁੰਜੀ ਵੱਲ ਵਾਪਸ ਜਾਣ ਦਾ ਕੋਈ ਰਾਹ ਨਹੀਂ ਅਤੇ ਪਾਸਫ਼੍ਰੇਜ਼ ਬਾਰੇ ਕੋਈ ਸੰਕੇਤ ਨਹੀਂ। ਅਮਲੀ ਵਿਕਲਪ ਕੁੰਜੀ ਦਾ ਅਧਿਕ੍ਰਿਤ ਬੈਕਅੱਪ, ਜਾਂ ਆਪਰੇਟਰ ਦੀ ਆਮ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਜਾਰੀ ਨਵੀਂ ਪਛਾਣ ਹਨ। ਪਾਸਫ਼੍ਰੇਜ਼ 'ਮੁੜ ਪ੍ਰਾਪਤ' ਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਵਾਲਾ ਹਰ ਵਿਅਕਤੀ ਇਸਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਰਿਹਾ ਹੈ।

ਖੁਲਾਸੇ ਲਈ ਵੱਖਰਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ। ਉਹੀ ਕੁੰਜੀ ਨਵੇਂ ਪਾਸਫ਼੍ਰੇਜ਼ ਨਾਲ ਮੁੜ ਇਨਕ੍ਰਿਪਟ ਕਰਨ ਨਾਲ ਕੁੰਜੀ ਸਮੱਗਰੀ ਅਣਬਦਲੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਕਿਤੇ ਹੋਰ ਪਹਿਲਾਂ ਹੀ ਖੋਲ੍ਹੀ ਗਈ ਕਾਪੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ। ਮੁਰੰਮਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਦ ਕਰਨਾ ਜਾਂ ਬਦਲਣਾ ਹੈ: ਨਵੀਂ ਕੁੰਜੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰੋ, ਵੰਡੋ, ਅਤੇ ਪੁਰਾਣੀ ਨੂੰ ਸਹਿਭਾਗੀ 'ਤੇ ਸੇਵਾਮੁਕਤ ਕਰੋ। ਜਦੋਂ ਤੱਕ ਇਹ ਨਹੀਂ ਹੁੰਦਾ, ਫਾਈਲ ਪਾਸਵਰਡ ਬਦਲਣਾ ਘਰੇਲੂ ਕੰਮ ਹੈ, ਨਿਯੰਤਰਣ ਨਹੀਂ। ਨਵੀਂ ਪਛਾਣ ਕੰਮ ਕਰਦੀ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਬਾਅਦ ਹੀ ਪੁਰਾਣੀ ਫਾਈਲ ਨੂੰ ਬੈਕਅੱਪ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਸੀਰੀਅਲ ਜਾਂ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨੇ ਇਸਨੂੰ ਬਦਲਿਆ।