ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲਾ ਵੈਧ ਕੋਡ ਵੀ VPN ਲੌਗਇਨ ਵਿੱਚ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ

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

ਪ੍ਰੋਂਪਟ ਦਾ ਕ੍ਰਮ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਪ੍ਰਵਾਹ ਵਿੱਚ ਹੋ

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

ਗਲਤ ਰੂਪ ਮਾੜੇ ਕੋਡ ਵਰਗਾ ਦਿਸਦਾ ਹੈ। ਸਿਰਫ਼ ਪਾਸਵਰਡ ਲਈ ਬਣੀ ਫੀਲਡ ਵਿੱਚ ਨਵਾਂ ਕੋਡ ਪੇਸਟ ਕਰੋ, ਅਤੇ ਸਰਵਰ ਉਸ ਨੂੰ ਪਾਸਵਰਡ ਦਾ ਹਿੱਸਾ ਸਮਝ ਕੇ ਪੜ੍ਹੇਗਾ। ਕਲਾਇੰਟ ਵੱਲ, OpenVPN 2.4 ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣ ਫ਼ਰਕ ਦਿਖਾਉਂਦੇ ਹਨ: AUTH_FAILED,CRV1: ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਰਵਰ ਚੁਣੌਤੀ-ਜਵਾਬ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਨੂੰ static-challenge ਜਾਂ SCRV1: ਰੂਪ ਵਾਲੀ ਪਾਸਵਰਡ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ਼ auth-user-pass ਵਾਲਾ ਪੁਰਾਣਾ ਪ੍ਰੋਫਾਈਲ ਪਾਸਵਰਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰਕੇ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਜੋ ਲੌਗ ਵਿੱਚ OTP ਫੇਲ੍ਹਤਾ ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਕੋਈ ਕੋਡ ਭੇਜਿਆ ਨਹੀਂ ਗਿਆ।

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

ਸਰਵਰ ਛੇ ਅੰਕਾਂ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

ਸਮੇਂ-ਆਧਾਰਿਤ ਕੋਡ RFC 6238 ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਜੋ RFC 4226 ਦੀ ਪੁਰਾਣੀ ਕਾਊਂਟਰ-ਆਧਾਰਿਤ ਬਣਾਵਟ ਨੂੰ ਲਪੇਟਦਾ ਹੈ: ਗਤੀਸ਼ੀਲ ਕਾਰਕ 'ਤੇ HMAC, ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਛੇ ਅੰਕਾਂ ਵਿੱਚ ਕੱਟਿਆ। TOTP ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਕਾਰਕ ਮੌਜੂਦਾ Unix ਸਮੇਂ ਨੂੰ ਇੱਕ ਕਦਮ ਨਾਲ ਭਾਗ ਦਿੱਤਾ ਹੋਇਆ ਹੈ, ਜੇ ਓਪਰੇਟਰ ਨੇ ਬਦਲਿਆ ਨਾ ਹੋਵੇ ਤਾਂ 30 ਸਕਿੰਟ। ਸਤਿਆਪਕ ਤੁਹਾਡੇ ਅੰਕਾਂ ਦੀ ਸੰਭਾਲੇ ਮੁੱਲ ਨਾਲ ਕਦੇ ਤੁਲਨਾ ਨਹੀਂ ਕਰਦਾ; ਉਹ ਸਾਂਝੇ ਬੀਜ ਤੋਂ ਉਮੀਦ ਕੀਤਾ ਕੋਡ ਦੁਬਾਰਾ ਗਿਣਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਗੁਆਂਢੀ ਕਦਮ ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਹੌਲੀ ਯਾਤਰਾ ਲੌਗਇਨ ਫੇਲ੍ਹ ਨਹੀਂ ਕਰਦੀ।

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

ਕਾਊਂਟਰ-ਆਧਾਰਿਤ ਟੋਕਨ ਹਰ ਦਬਾਅ 'ਤੇ ਕਾਊਂਟਰ ਅੱਗੇ ਵਧਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਕੋਡ ਬਣਨ ਤੋਂ ਬਾਅਦ ਕਦੇ ਨਾ ਭੇਜੇ ਜਾਣ 'ਤੇ ਉਹ ਤਾਲਮੇਲ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦੇ ਹਨ; ਆਮ ਹੱਲ ਅੱਗੇ ਦੇ ਕੁਝ ਮੁੱਲ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਮੁੜ-ਤਾਲਮੇਲ ਵਿੰਡੋ ਹੈ। ਜੇ ਓਪਰੇਟਰ ਨੇ HOTP ਰਜਿਸਟਰ ਕੀਤਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਐਪ TOTP ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਹਰ ਮੁੱਲ ਘੜੀ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਦਿਸਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਗਲਤ ਹੈ। QR ਕੋਡ ਪਿੱਛੇਲਾ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ URI ਕਿਸਮ, ਅੰਕ, ਮਿਆਦ ਅਤੇ ਹੈਸ਼ ਦੱਸਦਾ ਹੈ।

ਗਲਤ ਕੋਡ ਵਰਗੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ

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

ਦੂਜਾ, ਨਾ ਮਿਲਦਾ ਪੈਰਾਮੀਟਰ ਸੈੱਟ। ਅੱਠ ਅੰਕ, 60 ਸਕਿੰਟ ਦੀ ਮਿਆਦ ਜਾਂ SHA-256 ਨਾਲ ਰਜਿਸਟਰ ਕੀਤਾ ਬੀਜ ਅਜਿਹੇ ਕੋਡ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਛੇ ਅੰਕ, 30 ਸਕਿੰਟ ਅਤੇ SHA-1 ਦੀ ਉਮੀਦ ਕਰਨ ਵਾਲਾ ਸਤਿਆਪਕ ਰੱਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ ਇਹ ਗਲਤ ਕੋਡ ਤੋਂ ਵੱਖ ਨਹੀਂ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ। ਇਹ ਉਹਨਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਤੋਂ ਬਾਅਦ ਦਿਸਦਾ ਹੈ ਜਿੱਥੇ QR ਕੋਡ ਦੀ ਫ਼ੋਟੋ ਤੋਂ ਐਂਟਰੀ ਦੁਬਾਰਾ ਜੋੜੀ ਗਈ, ਜਾਂ ਟੋਕਨ ਰਿਕਾਰਡ ਡਿਫ਼ਾਲਟ ਮੁੱਲਾਂ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਇਆ ਗਿਆ।

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

ਇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਵਾਲਾ ਛੋਟਾ ਕ੍ਰਮ

ਸਭ ਤੋਂ ਸਸਤੀ ਜਾਂਚ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜੋ ਪਹਿਲਾ ਕਦਮ ਪੂਰਾ ਨਾ ਹੋਵੇ ਉੱਥੇ ਰੁਕੋ।

1. ਨਵੇਂ ਕੋਡ ਦੀ ਉਡੀਕ ਕਰੋ, ਇੱਕ ਵਾਰ ਭੇਜੋ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਚੁਣੌਤੀ ਪਾਸਵਰਡ ਸਵੀਕਾਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ ਜਾਂ ਬਾਅਦ ਵਿੱਚ।
2. ਪ੍ਰਮਾਣਕਾਰ ਦਾ ਲੇਬਲ ਸਰਵਰ ਵੱਲੋਂ ਸੰਭਾਲੇ ਉਪਭੋਗਤਾ-ਨਾਮ ਨਾਲ ਮਿਲਾਓ।
3. ਪੱਕਾ ਕਰੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਚੁਣੌਤੀ ਦਾ ਜਵਾਬ ਦੇ ਹੀ ਸਕਦਾ ਹੈ, ਉੱਪਰਲੇ CRV1 ਕੇਸ ਵਾਂਗ।
4. ਯੰਤਰ ਦੀ ਘੜੀ ਦੀ ਤੁਲਨਾ ਕਿਸੇ ਜਾਣੇ ਸਮੇਂ-ਸਰੋਤ ਨਾਲ ਕਰੋ; ਕੁਝ ਦਰਜਨ ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਵਿਚਲਨ TOTP ਨੂੰ ਆਪ ਹੀ ਤੋੜ ਦਿੰਦਾ ਹੈ।
5. ਟੋਕਨ TOTP ਹੈ ਜਾਂ HOTP, ਅਤੇ ਕਿਹੜੇ ਅੰਕ, ਮਿਆਦ ਤੇ ਹੈਸ਼ ਰਜਿਸਟਰ ਹੋਏ, ਇਹ ਓਪਰੇਟਰ ਨੂੰ ਪੁੱਛੋ।

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

ਬੀਜ ਅਤੇ ਰਿਕਵਰੀ ਕੋਡ ਚੱਕਰ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

ਕੋਡ ਲੌਗਇਨ ਪੇਜ ਨੂੰ ਭਰੋਸੇਯੋਗ ਵੀ ਨਹੀਂ ਬਣਾਉਂਦਾ: ਮਿਲਦੇ-ਜੁਲਦੇ ਡੋਮੇਨ 'ਤੇ OTP ਪ੍ਰੋਂਪਟ ਵੈਧ ਕੋਡ ਇਕੱਠਾ ਕਰਕੇ ਉਸੇ ਸਮੇਂ ਦੇ ਅੰਦਰ ਦੁਬਾਰਾ ਵਜਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕਿੱਥੇ ਲਿਖ ਰਹੇ ਹੋ ਇਹ ਅਜੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਹੀ ਦੱਸਦਾ ਹੈ।

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