Magic links ਬਨਾਮ passwords: takeover, ਈਮੇਲ ਡਿਲਿਵਰੇਬਿਲਟੀ ਅਤੇ ਐਂਟਰਪਰਾਈਜ਼ ਉਮੀਦਾਂ ਦੇ UX ਅਤੇ ਸੁਰੱਖਿਆ ਟਰੇਡ-ਆਫ ਬਾਰੇ ਜਾਣੋ।

ਲਾਗਿਨ ਉਹਨਾਂ ਚੰਦ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿੱਥੇ ਹਰ ਯੂਜ਼ਰ ਛੋਹਮਾਰਦਾ ਹੈ, ਅਕਸਰ ਪਹਿਲੇ ਦਿਨ। ਜੇ ਇਹ ਸੁਸਤ ਜਾਂ ਗੁੰਝਲਦਾਰ ਲੱਗੇ ਤਾਂ ਲੋਕ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਇਹ ਗਲਤ ਵਿਅਕਤੀ ਲਈ ਬਹੁਤ ਆਸਾਨ ਲੱਗੇ ਤਾਂ ਤੁਸੀਂ ਡੇਟਾ, ਪੈਸਾ ਜਾਂ ਖਾਤਿਆਂ ਦਾ ਨਿਯੰਤਰਣ ਗੁਆ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ magic links ਅਤੇ passwords ਵਿਚੋਂ ਚੋਣ ਸਿਰਫ UI ਪਸੰਦ ਨਹੀਂ — ਇਹ ਇੱਕ ਉਤਪਾਦ ਫੈਸਲਾ ਹੈ ਜਿਸਦੇ ਅਸਲ ਸੁਰੱਖਿਆ ਅਤੇ ਸਹਾਇਤਾ ਖਰਚ ਹੁੰਦੇ ਹਨ।
ਜਦ ਲੋਕ “ਖਤਰਾ” ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਹਕੀਕਤੀ ਸਵਾਲਾਂ ਦਾ ਮਤਲਬ ਲੈਂਦੇ ਹਨ: ਕੀ ਕੋਈ ਵਿਅਕਤੀ ਪੈਸਾ ਖਰਚ ਸਕਦਾ ਹੈ, ਨਿੱਜੀ ਡੇਟਾ ਦੇਖ ਸਕਦਾ ਹੈ, ਸੈਟਿੰਗ ਬਦਲ ਸਕਦਾ ਹੈ, ਜਾਂ ਹੋਰ ਯੂਜ਼ਰਾਂ 'ਤੇ ਅਸਰ ਪਾ ਸਕਦਾ ਹੈ? ਇੱਕ ਸਿਰਫ ਪੜ੍ਹਨ ਵਾਲਾ ਨਿਊਜ਼ਲੈਟਰ ਖਾਤਾ ਘੱਟ ਖਤਰਾ ਹੈ। ਇੱਕ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ, ਬਿਲਿੰਗ ਪੇਜ, ਜਾਂ ਗਾਹਕ ਡੇਟਾ ਵਾਲਾ ਵਰਕਸਪੇਸ ਉੱਚ-ਖਤਰਾ ਹੈ। ਤੁਹਾਡਾ ਲਾਗਿਨ ਢੰਗ ਉਸ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਗਲਤ ਚੋਣ ਮਹੰਗੀ ਪੈਂਦੀ ਹੈ। ਲੌਕਆਊਟ ਸਪੋਰਟ ਟਿਕਟਾਂ ਅਤੇ ਮੈਨੁਅਲ ਰਿਕਵਰੀ ਕੰਮ ਬਣਾਉਂਦੇ ਹਨ। ਚਿੜਚਿੜੇ ਲਾਗਿਨ churn ਬਣਾਉਂਦੇ ਹਨ: ਲੋਕ ਸਾਈਨ-ਅਪ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਵਾਪਸ ਨਹੀਂ ਆਂਦੇ, ਜਾਂ ਦੂਜੇ ਖਾਤੇ ਬਣਾਉਂਦੇ ਹਨ। ਅਤੇ ਜੇ ਹਮਲਾਵਰ ਘੁਸ ਆ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਰਿਫੰਡ, ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਅਤੇ ਭਰੋਸੇ ਦੀ ਕੀਮਤ ਚੁਕਾਉਣੀ ਪੈਂਦੀ ਹੈ।
ਹਰ ਐਪ ਲਈ ਇੱਕ ਹੀ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਦਰਸ਼ਕ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ। ਕੁਝ ਯੂਜ਼ਰ ਕਲਾਸਿਕ ਪਾਸਵਰਡ ਨਾਲ ਵਾਧੂ ਜਾਂਚਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਦੂਜੇ “ਮੈਨੂੰ ਲਿੰਕ ਭੇਜੋ” ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਕਦੇ ਵੀ ਕ੍ਰੈਡੇਂਸ਼ਲ ਚਿੰਤਾ ਨਹੀਂ ਕਰਦੇ।
ਫੈਸਲੇ ਲਈ ਇੱਕ ਉਪਯੋਗ ਫਰੇਮ ਵਰਗਾ:
ਇਕਲ ਲੇਖਕ ਟੂਲ ਪਹਿਲੀ ਲਾਗਿਨ ਤੇ ਤੇਜ਼ੀ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦਾ ਹੈ। ਟੀਮ ਉਤਪਾਦ ਜਿਸ ਵਿੱਚ ਐਡਮਿਨ ਰੋਲ ਹੁੰਦੇ ਹਨ ਆਮ ਤੌਰ 'ਤੇ ਮੁੜ ਤੋਂ ਮਜ਼ਬੂਤ ਨਿਯੰਤਰਣਾਂ ਅਤੇ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਇੱਕ ਸਪਸ਼ਟ ਰਿਕਵਰੀ ਕਹਾਣੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Magic link ਯੂਜ਼ਰ ਨੂੰ ਪਾਸਵਰਡ ਟਾਈਪ ਕੀਤੇ ਬਿਨਾਂ ਸਾਈਨ-ਇਨ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਉਹ ਈਮੇਲ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਤੁਹਾਡੀ ਐਪ ਇਕ ਸੁਨੇਹਾ ਭੇਜਦੀ ਹੈ, ਅਤੇ ਉਹ ਉਸ ਈਮੇਲ ਵਿੱਚ ਲਿੰਕ (ਜਾਂ ਬਟਨ) 'ਤੇ ਕਲਿਕ ਕਰਕੇ ਸਾਈਨ-ਇਨ ਕਰ ਲੈਂਦਾ ਹੈ।
ਚੰਗੇ ਦਿਨ 'ਤੇ, ਇਹ ਬੇਪਰੇਸ਼ਾਨੀ-ਰਹਿਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਈਮੇਲ ਟਾਈਪ ਕਰੋ, ਇਨਬੌਕਸ ਖੋਲ੍ਹੋ, ਕਲਿਕ ਕਰੋ, ਹੋ ਗਿਆ। ਇਸੀ ਲਈ ਟੀਮਾਂ magic links 'ਤੇ ਸੋਚਦੀਆਂ ਹਨ ਜਦ ਉਹ "ਭੁੱਲ ਗਿਆ ਪਾਸਵਰਡ" ਘਟਾਉਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ।
ਅਕਸਰ magic links ਇੱਕ ਵਾਰੀ ਵਰਤਣ ਜੋਗੇ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਯੂਜ਼ਰ ਦੇ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲਿੰਕ ਜਲਦੀ expire ਹੋ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਅਕਸਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ) ਤਾਂ ਜੋ ਪੁਰਾਣੇ ਈਮੇਲ ਥ੍ਰੈੱਡ ਤੋਂ ਦੁਬਾਰਾ ਵਰਤਿਆ ਨਾ ਜਾ ਸਕੇ। ਜੇ ਤੁਸੀਂ ਲੰਬੀ ਮਿਆਦ ਵਾਲੇ ਜਾਂ reusable ਲਿੰਕ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਚਾਬੀ ਵਾਂਗ ਲੈੋ — ਇਹ ਸੁਵਿਧਾਜਨਕ ਹਨ, ਪਰ ਜੇ ਈਮੇਲ ਫਾਰਵਰਡ ਹੋ ਜਾਏ, ਕਈ ਡਿਵਾਈਸਾਂ 'ਤੇ sync ਹੋ ਜਾਏ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਨੇ ਐਕਸੈੱਸ ਕਰ ਲਿਆ ਤਾਂ ਖਤਰਨਾਕ ਹੋ ਸਕਦੇ ਹਨ।
ਆਮ ਰੂਪਾਂ ਵਿੱਚ ਸਾਫ-ਸੁਥਰਾ “ਕਲਿੱਕ ਕਰ ਕੇ ਸਾਈਨ-ਇਨ” ਲਿੰਕ, ਇੱਕ ਛੋਟਾ ਕੋਡ (ਅਕਸਰ 6 ਅੰਕ) fallback ਵਜੋਂ, ਜਾਂ "ਇਸ ਡਿਵਾਈਸ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ" ਫਲੋ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ ਜਿੱਥੇ ਯੂਜ਼ਰ ਦੂਜੇ ਪਹਿਲਾਂ-ਸਾਈਨ-ਇਨ ਡਿਵਾਈਸ ਤੋਂ ਲੌਗਿਨ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ।
ਛੁਪਿਆ ਨਿਰਭਰਤਾ ਈਮੇਲ ਐਕਸੈੱਸ ਅਤੇ ਗਤੀ ਹੈ। ਜੇ ਈਮੇਲ ਦੇਰੀ ਨਾਲ ਆਏ, spam ਵਿੱਚ ਜਾਏ, ਜਾਂ ਯੂਜ਼ਰ ਆਫਲਾਈਨ ਹੋਵੇ, ਤਾਂ ਲਾਗਿਨ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਜਦ ਡਿਲਿਵਰੇਬਿਲਟੀ ਮਜ਼ਬੂਤ ਹੋਵੇ ਤਾਂ magic links ਸ਼ਾਨਦਾਰ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਜਦ ਨਹੀਂ ਹੋਵੇ ਤਾਂ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਨਿਰਾਸ਼ ਕਰਨ ਵਾਲੇ ਹੋ ਸਕਦੇ ਹਨ।
ਪਾਸਵਰਡ ਲਾਗਿਨ ਅਕਸਰ ਸਿਰਫ ਇਕ ਫਾਰਮ ਫੀਲਡ ਨਹੀਂ ਹੁੰਦਾ। ਜਿਆਦਾਤਰ ਉਤਪਾਦ ਇਸਨੂੰ ਈਮੇਲ ਵੇਰੀਫਿਕੇਸ਼ਨ, reset ਫਲੋ, ਡਿਵਾਈਸ ਚੈੱਕਸ, ਅਤੇ ਅਕਸਰ multi-factor authentication (MFA) ਨਾਲ ਜੋੜਦੇ ਹਨ। ਜਦ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ ਜਾਣ-ਪਹਚਾਣ ਅਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ। ਜਦ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਇਹ ਚਿੜਚਿੜਾ ਕਰ ਸਕਦਾ ਹੈ।
ਆਧੁਨਿਕ ਪਾਸਵਰਡ UX ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ: ਪਾਸਵਰਡ ਬਣਾਓ, ਆਪਣੀ ਈਮੇਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਕਈ ਵਾਰੀ ਦੂਜਾ ਕਦਮ ਪੂਰਾ ਕਰੋ (authenticator ਕੋਡ, SMS, ਜਾਂ hardware key) ਜਦ ਸਾਈਨ-ਇਨ ਖਤਰਨਾਕ ਲੱਗੇ। ਟੀਮਾਂ ਰੇਟ ਲਿਮਿਟ, ਬੌਟ ਚੈੱਕ, ਅਤੇ “ਨਵਾਂ ਸਾਈਨ-ਇਨ Chrome ਤੇ Windows ਤੋਂ” ਵਰਗੇ ਅਲਰਟ ਜੋੜਦੀਆਂ ਹਨ। ਯੂਜ਼ਰ ਅਕਸਰ ਉਹਨਾਂ ਨੂੰ ਨੋਟਿਸ ਨਹੀਂ ਕਰਦੇ ਜਦ ਤੱਕ ਕੁਝ ਗਲਤ ਨਾ ਹੋਵੇ।
ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਦਿਨ-ਪਰ-ਦਿਨ ਦੀ ਹਕੀਕਤ ਬਦਲ ਚੁੱਕੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਹੁਣ ਪਾਸਵਰਡ ਟਾਈਪ ਨਹੀਂ ਕਰਦੇ। ਉਹ Face ID, ਬਰਾਉਜ਼ਰ ਪ੍ਰੋੰਪਟ, ਜਾਂ autofill ਵਰਤਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਫਾਰਮ autofill ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ ਅਤੇ paste ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਮਜ਼ਬੂਤ, ਵਿਲੱਖਣ ਪਾਸਵਰਡ ਵੀ ਦਰਦ-ਰਹਿਤ ਹੋ ਸਕਦੇ ਹਨ।
ਪਰ ਮੁੱਖ ਸਮਾਂਹ ਹਮੇਸ਼ਾ “ਮੈਂ ਆਪਣਾ ਪਾਸਵਰਡ ਭੁੱਲ ਗਿਆ” ਹੀ ਰਹਿੰਦਾ ਹੈ। ਯੂਜ਼ਰ ਕੁਝ ਵਾਰੀ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ, reset ਈਮੇਲ ਮੰਗਦੇ ਹਨ, ਇਨਬੌਕਸ 'ਤੇ ਜਾਂਦੇ ਹਨ, ਫਿਰ ਨਵੇਂ ਪਾਸਵਰਡ ਨੂੰ ਤਿਆਰ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ reset ਈਮੇਲ ਧੀਮੀ, ਫਿਲਟਰ ਕੀਤੀ ਜਾਂ ਗੁੰਝਲਦਾਰ ਹੋਵੇ ਤਾਂ ਸਾਰਾ ਲਾਗਿਨ ਤਜਰਬਾ ਟੁਟਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਪਾਸਵਰਡ ਮਜ਼ਬੂਤ ਹੋ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਲਈ ਮੁਸ਼ਕਲ ਹੋਏ। ਲੰਬੇ passphrases ਦੀ ਆਗਿਆ ਦਿਓ, ਖਾਲੀ ਥਾਂ ਅਤੇ ਖ਼ਾਸ ਅੱਖਰਾਂ ਨੂੰ ਸਵੀਕਾਰੋ, ਅਜਿਹੀਆਂ ਅਜੀਬ ਨੀਤੀਆਂ ਤੋਂ ਬਚੋ, ਅਤੇ ਵਿਲੱਖਣਤਾ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰੋ। ਵਿਕਲਪਿਕ MFA ਅਤੇ ਮੈਨੇਜਰ-ਦੋਸਤ ਫਾਰਮ ਜੋੜੋ, ਅਤੇ ਪਾਸਵਰਡ ਕਈ ਉਤਪਾਦਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਡਿਫ਼ਾਲਟ ਰਹਿੰਦਾ ਹੈ।
ਇਹ ਬਹਸ ਅਕਸਰ ਸੁਰੱਖਿਆ ਵਿਰੁੱਧ ਸੁਵਿਧਾ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਇਸਨੂੰ ਤੇਜ਼ੀ ਅਤੇ friction ਦੇ ਤੌਰ 'ਤੇ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਸਭ ਤੋਂ ਵੱਡਾ ਫਰਕ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਪਹਿਲੇ ਦਿਨ।
ਪਹਿਲੀ ਲਾਗਿਨ ਲਈ, magic links ਤੇਜ਼ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕੁਝ ਬਣਾਉਣ ਜਾਂ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਪਾਸਵਰਡ ਪਹਿਲੀ ਵਾਰੀ ਲੰਬੇ ਸਮੇਂ ਲੈ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਲੋਕ ਉਹਨਾਂ ਨੂੰ “ਪਰਯਾਪਤ ਚੰਗਾ” ਚੁਣਨ ਲਈ ਰੁਕਦੇ ਹਨ, ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ, ਫਿਰ ਕਿਸੇ ਅਣਪੇਖੇ ਨਿਯਮ 'ਤੇ ਫਸ ਜਾਂਦੇ ਹਨ।
ਦੋਹਰਾਈ ਲਾਗਿਨ ਲਈ, ਫਾਇਦਾ ਉਲਟ ਹੋ ਸਕਦਾ ਹੈ। ਨਵੇਂ ਡਿਵਾਈਸ 'ਤੇ ਕੋਈ ਹੋਵੇ ਤਾਂ magic link ਦਾ ਅਰਥ ਈਮੇਲ ਦੀ ਉਡੀਕ ਅਤੇ ਐਪ ਬਦਲਣਾ ਹੋ ਸਕਦਾ ਹੈ। ਪਾਸਵਰਡ ਇਕ ਤੇਜ਼ autofill ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਜੇ ਪਾਸਵਰਡ ਸੇਵ ਨਾ ਹੋਵੇ ਤਾਂ ਦੋਹਰਾਈ ਲਾਗਿਨ reset ਲੂਪ ਬਣ ਜਾਂਦਾ ਹੈ।
ਨਵੇਂ-ਡਿਵਾਈਸ ਸਾਈਨ-ਇਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਮਹਿਸੂਸਾਤ ਤੇਜ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। magic links ਨਾਲ ਯੂਜ਼ਰ ਸੋਚਦੇ ਹਨ, “ਮੈਨੂੰ ਫਿਰ ਤੋਂ ਈਮੇਲ ਕਿਉਂ ਆ ਰਹੀ ਹੈ?” ਪਾਸਵਰਡਾਂ ਨਾਲ ਯੂਜ਼ਰ ਸੋਚਦੇ ਹਨ, “ਕੀ ਮੈਂ ਯਾਦ ਰੱਖਦਾ ਹਾਂ?” ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਜਾਂਚਾਂ ਕਦਮ ਜੋੜਦੀਆਂ ਹਨ, ਅਤੇ ਛੋਟੀ-ਸੈਸ਼ਨ ਵਾਲੇ ਉਤਪਾਦ ਉਹ ਰੁਕਾਵਟ ਜ਼ਿਆਦਾ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਘੱਟ ਕਨੈਕਟਿਵਿਟੀ magic links ਨੂੰ ਨਾਜੁਕ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਈਮੇਲ ਸਿੰਕ ਧੀਮੀ ਹੈ ਤਾਂ ਯੂਜ਼ਰ ਫਸ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੀ ਐਪ ਠੀਕ ਹੋ। ਪਾਸਵਰਡ ਸਾਈਨ-ਇਨ ਵੀ ਇੰਟਰਨੈੱਟ ਬਿਨਾਂ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ।
ਸਾਂਝੇ ਡਿਵਾਈਸ ਖਤਰੇ ਨੂੰ ਵੀ ਬਦਲ ਦਿੰਦੇ ਹਨ:
ਇਸ ਲਈ ਇੱਕ ਸਪਸ਼ਟ sign-out ਬਟਨ, ਦਿੱਖ ਵਾਲੇ session ਕੰਟਰੋਲ, ਅਤੇ ਸੋਝੀ ਸਮੇਂ-ਆਧਾਰਿਤ timeouts ਅਕਸਰ ਲਾਗਿਨ ਵਿਧੀ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੇ ਹਨ।
ਈਮੇਲ ਬਦਲਾਅ ਵੀ ਇੱਕ ਦਰਦ-ਬਿੰਦੂ ਹੈ। ਜੇ ਕੋਈ ਆਪਣੀ ਇਨਬੌਕਸ ਦੀ ਪਹੁੰਚ ਗੁਆ ਬੈਠਦਾ ਹੈ ਤਾਂ magic-link ਖਾਤਿਆਂ ਦੀ recovery ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀ ਹੈ। password ਖਾਤੇ ਈਮੇਲ ਬਦਲਣ ਨੂੰ ਸਹਾਇਤ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਤੁਸੀਂ verified updates ਨੂੰ ਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਪਰ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਐਸੀ recovery ਚਾਹੀਦੀ ਹੈ ਜੋ ਸਿਰਫ ਗੁਆਈ ਈਮੇਲ ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੇ।
ਦੋਹਾਂ ਤਰੀਕੇ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਦੋਹਾਂ ਫੇਲ ਵੀ ਹੋ ਸਕਦੇ ਹਨ। “Passwordless” ਦਾ ਮਤਲਬ “ਖਤਰਾ-ਮੁਕਤ” ਨਹੀਂ ਹੁੰਦਾ।
Magic link ਸਿਰਫ ਉਤਨਾ ਹੀ ਮਜ਼ਬੂਤ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਇਨਬੌਕਸ ਅਤੇ ਈਮੇਲ ਦਾ ਰਾਹ ਹੈ। ਆਮ takeover ਰਾਹ:
ਮੁੱਖ ਖਤਰੇ ਦਾ ਪੈਟਰਨ ਸਧਾਰਣ ਹੈ: ਜੋ ਕੋਈ ਵੀ ਉਸ ਈਮੇਲ ਨੂੰ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਉਹ ਸਾਈਨ-ਇਨ ਕਰ ਸਕਦਾ ਹੈ।
ਪਾਸਵਰਡ ਜ਼ਿਆਦਾਤਰ ਪੇਸ਼ਗੋਈ ਯੋਗ, ਉੱਚ-ਵੋਲਿਊਮ ਤਰੀਕਿਆਂ ਵਿੱਚ fail ਹੁੰਦੇ ਹਨ:
ਪਾਸਵਰਡ ਨਾਲ, ਹਮਲਾਵਰ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਈਮੇਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹ ਕਿਸੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪਾਸਵਰਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਬੋਟ ਇਸਨੂੰ ਲੱਭਣ 'ਚ ਚੰਗੇ ਹਨ।
ਸੈਸ਼ਨ ਦੀ ਲੰਬੀ ਮਿਆਦ ਅਤੇ ਡਿਵਾਈਸ ਟਰੱਸਟ ਦੋਹਾਂ ਲਈ ਮੈਟਰ ਕਰਦੇ ਹਨ। ਲੰਬੇ ਸੈਸ਼ਨ friction ਘਟਾਉਂਦੇ ਹਨ ਪਰ ਜੇ ਲੈਪਟਾਪ ਚੋਰੀ ਹੋ ਜਾਵੇ ਤਾਂ ਨੁਕਸਾਨ ਵੱਧ ਜਾਂਦਾ ਹੈ। “Trusted devices” ਤੁਹਾਨੂੰ ਨਵੇਂ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵਾਧੂ ਚੈਕਸ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਹਰ ਲਾਗਿਨ ਨੂੰ ਸਜ਼ਾ ਦੇਣ ਦੇ।
MFA ਦੋਹਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਫਿਟ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਪਾਸਵਰਡ ਤੋਂ ਬਾਅਦ ਜਾਂ magic-link ਕਲਿੱਕ ਤੋਂ ਬਾਅਦ ਦੂਜਾ ਕਦਮ ਜੋੜ ਸਕਦੇ ਹੋ। ਮਜ਼ਬੂਤ ਸੈਟਅੱਪ ਨਵੇਂ ਡਿਵਾਈਸਾਂ, ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਖਾਤਾ ਬਦਲਾਅ ਤੇ MFA ਲਗਾਉਂਦੇ ਹਨ, ਸਿਰਫ ਲਾਗਿਨ 'ਤੇ ਨਹੀਂ।
Magic links ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ ਕਿਉਂਕਿ ਲਾਗਿਨ ਕਦਮ ਇਨਬੌਕਸ 'ਤੇ ਚਲ ਹੁੰਦਾ ਹੈ। ਇਸਦਾ ਇਹ ਵੀ ਅਰਥ ਹੈ ਕਿ ਤੁਹਾਡਾ ਲਾਗਿਨ ਡਿਲਿਵਰੇਬਿਲਟੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: spam ਫਿਲਟਰ, ਭੇਜਣ ਦੀ ਹੱਦ, ਅਤੇ ਦੇਰੀ। ਪਾਸਵਰਡ ਨਾਲ, ਧੀਮੀ ਈਮੇਲ ਜਿਆਦਾਤਰ ਠੀਕ-Reset ਵਕਤ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ। ਪਰ magic links ਲਈ ਇਹ ਹਰ ਲਾਗਿਨ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ।
ਪ੍ਰੋਵਾਇਡਰ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਸੰਦੇਸ਼ ਸ਼ੱਕੀ ਲੱਗਦਾ ਹੈ, ਭੇਜਣ ਵਾਲੇ ਦੀ ਸakhਣਤਾ, ਸਮੱਗਰੀ, ਅਤੇ ਯੂਜ਼ਰ ਵ੍ਯਵਹਾਰ ਦੇ ਆਧਾਰ 'ਤੇ। ਕੁਝ ਪ੍ਰੋਵਾਈਡਰ ਇਕੋ-ਜਿਹੇ ਸੁਨੇਹਿਆਂ ਦੇ ਬਰਸਟ ਨੂੰ throttle ਵੀ ਕਰਦੇ ਹਨ। ਜੇ ਯੂਜ਼ਰ “ਮੈਨੂੰ ਲਿੰਕ ਭੇਜੋ” ਤਿੰਨ ਵਾਰ ਟੈਪ ਕਰਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਲਗਭਗ ਇਕੋ-ਜਿਹੇ ਤਿੰਨ ਸੁਨੇਹੇ ਭੇਜ ਸਕਦੇ ਹੋ, ਜੋ ਧੀਮੇ ਹੋ ਸਕਦੇ ਹਨ ਜਾਂ ਫਲੈਗ ਹੋ ਸਕਦੇ ਹਨ।
ਜਦ ਈਮੇਲ ਅਣਭਰੋਸੇਯੋਗ ਹੁੰਦੀ ਹੈ, ਫੇਲਿਅਰ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ। ਯੂਜ਼ਰ ਸੋਚਦੇ ਨਹੀਂ "ਡਿਲਿਵਰੇਬਿਲਟੀ ਮਸਲਾ ਹੈ" — ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਟੁੱਟਿਆ ਹੈ। ਆਮ ਨਤੀਜੇ:
ਕਾਰਪੋਰੇਟ ਗੇਟਵੇਜ਼ ਸੁਨੇਹਿਆਂ ਨੂੰ ਚੁੱਪਚਾਪ quarantine ਕਰ ਸਕਦੇ ਹਨ। ਸਾਂਝੀਆਂ ਇਨਬੌਕਸ (ਜਿਵੇਂ support@) ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਿਸ ਕਿਸੇ ਕੋਲ ਵੀ ਐਕਸੈੱਸ ਹੈ ਉਹ ਲਿੰਕ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ। ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਲਿੰਕਾਂ ਨੂੰ ਓਥੇ ਭੇਜ ਸਕਦੇ ਹਨ ਜਿੱਥੇ ਯੂਜ਼ਰ ਜਾਂ ਅਜੇ ਨਹੀਂ ਦੇਖਦੇ।
ਜੇ ਤੁਸੀਂ magic links ਚੁਣਦੇ ਹੋ ਤਾਂ “ਈਮੇਲ ਡਾਊਨ” ਦਿਨਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਬੁਨਿਆਦੀ fallback support ਲੋਡ ਅਤੇ ਛੱਡਣ ਘਟਾ ਸਕਦੀ ਹੈ। ਇਹ ਇੱਕ ਵਾਰੀ-ਉਪਯੋਗ ਕੋਡ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਟਾਈਪ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ authenticator-ਆਧਾਰਤ ਮੈਥਡ, ਜਾਂ ਇੱਕ password ਬੈਕਅੱਪ। ਕਈ ਐਪਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਜਵਾਬ ਇਹ ਹੈ: “magic links ਮੁੱਖ ਦਰਵਾਜ਼ਾ ਹਨ, ਪਰ ਇਹ ਇਕੱਲਾ ਰਸਤਾ ਨਹੀਂ।”
ਐਂਟਰਪਰਾਈਜ਼ ਖਰੀਦਦਾਰ ਅਕਸਰ “magic links ਜਾਂ passwords?” ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ “ਕੀ ਇਹ ਸਾਡੇ identity ਸਿਸਟਮ ਨਾਲ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਕੰਟਰੋਲ ਕਰ ਸਕਦੇ ਹਾਂ?” ਕੇਂਦਰੀ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕਰਨ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਣ ਹੋਂਦਾ ਹੈ।
Single sign-on (SSO) ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾ ਚੈੱਕਬਾਕਸ ਹੁੰਦਾ ਹੈ। ਕਈ ਕੰਪਨੀਆਂ ਚਾਹੁੰਦੀਆਂ ਹਨ ਕਿ ਕਰਮਚਾਰੀ ਮੌਜੂਦਾ identity provider ਨਾਲ ਸਾਈਨ-ਇਨ ਕਰਨ, ਨ ਕਿ ਅਲੱਗ password database ਜਾਂ ਨਿੱਜੀ ਇਨਬੌਕਸ। SAML ਜਾਂ OIDC ਵਰਗੇ SSO ਮਿਆਰਾਂ ਦੀ ਉਮੀਦ ਕਰੋ ਅਤੇ ਡੋਮੇਨ, ਗਰੁੱਪ, ਜਾਂ ਮਨਜ਼ੂਰ ਕੀਤੇ ਯੂਜ਼ਰਾਂ ਦੁਆਰਾ ਪਹੁੰਚ ਸੀਮਤ ਕਰਨ ਵਰਗੇ ਨਿਯੰਤਰਣ।
ਉਹ ਲਾਗ-ਟਰੇਲ ਨੂੰ ਵੀ ਚਾਹੁੰਦੇ ਹਨ: ਸਾਈਨ-ਇਨ, ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ, ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਮੁੱਖ ਬਦਲਾਅ ਦੀ ਟੈਮਪਰ-ਰੋਧੀ ਲਾਗ। ਲਾਗਾਂ ਦੇ ਨਾਲ, ਕਈ ਟੀਮਾਂ ਪਹੁੰਚ ਰਿਵੀਊ ਚਲਾਉਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਹੋ ਸਕੇ ਕਿ ਸਹੀ ਲੋਕਾਂ ਕੋਲ ਅਜੇ ਵੀ ਸਹੀ ਪਹੁੰਚ ਹੈ।
MFA ਐਂਟਰਪਰਾਈਜ਼ ਵਿੱਚ ਕਦਾਚਿਤ ਵਿਕਲਪਿਕ ਨਹੀਂ ਰਹਿੰਦੀ। ਖਰੀਦਦਾਰ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਸਿਰਫ ਸਹਾਰਾ ਨਹੀਂ। ਉਹ ਐਡਮਿਨ ਲਈ MFA ਲਾਜ਼ਮੀ ਕਰਨ, ਜੋਖਿਮ ਵਾਲੇ ਲਾਗਿਨ ਬਲੋਕ ਕਰਨ, session timeouts ਅਤੇ re-auth ਨੀਤੀਆਂ, ਅਤੇ recovery ਕੰਟਰੋਲ ਬਾਰੇ ਪੁੱਛਣਗੇ।
ਐਡਮਿਨ ਰੋਲ ਹੋਰ ਇਕ ਝਟਕਾ ਬਣ ਜਾਂਦੇ ਹਨ। ਐਂਟਰਪਰਾਈਜ਼ least privilege ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਸਪੋਰਟ ਸਟਾਫ਼ ਦਾ ਪਾਵਰ ਬਿਲਿੰਗ ਐਡਮਿਨ ਵਾਂਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਬਿਲਿੰਗ ਐਡਮਿਨ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲਣ ਵਾਲੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ (exports, payment changes, project delete) ਲਈ step-up authentication ਆਮ ਹੈ ਭਾਵੇਂ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਹੀ ਸਾਈਨ-ਇਨ ਹੋਵੇ।
ਖਰੀਦ ਪ੍ਰਕਿਰਿਆ account lifecycle ਬਾਰੇ ਵੀ ਪੁੱਛਦੀ ਹੈ: ਖਾਤੇ ਕੌਣ ਬਣਾਉਂਦਾ ਹੈ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਕੀ ਪਹੁੰਚ ਨਵੀਨੀਕਰਨ ਟੀਮ ਚੱਲਣ 'ਤੇ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਇੰਟਰਨਲ ਟੂਲ ਜਾਂ SaaS ਉਤਪਾਦ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਸਵਾਲ ਅਰੰਭ ਤੋਂ ਹੀ ਉਠਦੇ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਮਦਦਗਾਰ ਹੈ।
ਲਾਗਿਨ ਨੂੰ ਸਭ ਲਈ ਇੱਕ ਫੈਸਲਾ ਮੰਨ ਕੇ ਅਪਣਾਉਣਾ ਅਕਸਰ ਦੋਹਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਖਰਾਬ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ: ਆਮ ਯੂਜ਼ਰਾਂ ਲਈ ਵਾਧੂ friction ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਖਾਤਿਆਂ ਲਈ ਕਮਜ਼ੋਰ ਰੱਖਿਆ।
ਯੂਜ਼ਰਾਂ ਨੂੰ ਗਰੁੱਪ ਵਿੱਚ ਵੰਡ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਉਪਭੋਕ্তা ਜੋ صرف ਆਪਣਾ ਡੇਟਾ ਵੇਖ ਸਕਦਾ ਹੈ, ਕਰਮਚਾਰੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦਾ। ਐਡਮਿਨ ਅਤੇ ਫਾਇਨੈਨਸ ਰੋਲ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੀ ਸ਼੍ਰੇਣੀ ਦੇ ਯੋਗ ਹਨ।
ਫਿਰ ਹਰ ਗਰੁੱਪ ਲਈ ਇਹ ਨਕਸ਼ਾ ਬਣਾਓ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ। “ਦੇਖੋ” ਘੱਟ ਪ੍ਰਭਾਵ ਹੈ। “ਸੰਪਾਦਨ”, “ਐਕਸਪੋਰਟ”, “ਰੋਲ ਬਦਲਣਾ”, ਅਤੇ “ਪੇਅਆਊਟ” ਉੱਚ-ਪ੍ਰਭਾਵ ਹਨ ਕਿਉਂਕਿ ਇਕ ਚੋਰੀ ਹੋਈ ਸੈਸ਼ਨ ਨਾਂ ਮਾਤਰ ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ balki ਅਸਲ ਨੁਕਸਾਨ ਵੀ ਕਰ ਸਕਦੀ ਹੈ।
ਕਈ ਟੀਮਾਂ ਲਈ ਇੱਕ ਸਧਾਰਣ ਪਹੁੰਚ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ:
ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੋਣ ਇੱਕ ਮਿਲਾਪ ਬਣ ਜਾਣਦੀ ਹੈ, ਨਾ ਕਿ ਇਕ ਲੜਾਈ। ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, Koder.ai 'ਤੇ ਬਣੇ ਉਤਪਾਦ ਲਈ ਤੁਸੀਂ ਨਿਯਮਤ ਬਿਲਡਰਾਂ ਲਈ ਘੱਟ friction ਵਾਲਾ sign-in ਦੇ ਸਕਦੇ ਹੋ, ਫਿਰ ਐਸੇ ਕਾਰਜਾਂ ਲਈ ਜੋ source code export, billing ਬਦਲਣ, ਜਾਂ ਟੀਮ ਮੈਨੇਜਮੈਂਟ ਵਰਗੇ ਹਨ, ਮਜ਼ਬੂਤ ਚੈੱਕ ਲਗਾ ਸਕਦੇ ਹੋ।
ਆਖ਼ਿਰ ਕਾਰ, ਸਾਰੀ ਯਾਤਰਾ ਨੂੰ ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ। ਵੇਖੋ ਉਹ ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਲਾਗਿਨ ਡ੍ਰਾਪ-ਆਫ, ਪਹਿਲੀ ਸਫਲਤਾ ਤੱਕ ਦਾ ਸਮਾਂ, ਅਤੇ ਲੌਕਆਉਟ ਟਿਕਟ ਟਰੈਕ ਕਰੋ। ਜੇ ਈਮੇਲ ਫਲੋ ਦਾ ਹਿੱਸਾ ਹੈ ਤਾਂ ਡਿਲਿਵਰੇਬਿਲਟੀ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ “ਕੋਈ ਈਮੇਲ ਨਹੀਂ ਆਈ” ਲਾਗਿਨ ਅਸਫਲਤਾ ਹੈ ਭਾਵੇਂ ਤੁਹਾਡਾ auth ਸਿਸਟਮ ਠੀਕ ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਅਸਲ ਉਤਪਾਦਾਂ ਵਿੱਚ ਸੋਚਣਾ ਟਰੇਡ-ਆਫ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
ਦ੍ਰਿਸ਼ A: ਇਕ ਘੱਟ-ਖਤਰੇ ਵਾਲਾ ਨਿਊਜ਼ਲੈਟਰ ਐਪ (ਸਿਰਫ ਮੂਲ ਪ੍ਰੋਫਾਈਲ ਡੇਟਾ)
ਡਿਫ਼ਾਲਟ: ਈਮੇਲ ਰਾਹੀਂ magic links.
ਰੀਡਰ ਘੱਟ friction ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ takeover ਦਾ ਪ੍ਰਭਾਵ ਅਕਸਰ ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ (ਕਿਸੇ ਨੇ ਪ੍ਰੇਫਰੰਸ ਬਦਲ ਸਕਦੇ ਹਨ)। ਮੁੱਖ ਫੇਲ-ਮੋਡ ਡਿਲਿਵਰੇਬਿਲਟੀ ਹੈ: ਦੇਰੀ ਵਾਲੀਆਂ ਈਮੇਲਾਂ, spam ਫਿਲਟਰ, ਯੂਜ਼ਰਾਂ ਦਾ “ਫੇਰ ਭੇਜੋ” ਅਤੇ ਫਿਰ ਇੱਕ ਪੁਰਾਣਾ expire ਹੋਇਆ ਲਿੰਕ ਕਲਿੱਕ ਕਰ ਦੇਣਾ ਅਤੇ ਹਾਰ ਮੰਨ ਲੈਣਾ।
ਦ੍ਰਿਸ਼ B: ਇੱਕ SaaS ਐਪ ਜਿਸ ਵਿੱਚ ਬਿੱਲਿੰਗ ਅਤੇ ਟੀਮ ਖਾਤੇ ਹਨ
ਡਿਫ਼ਾਲਟ: passwords (ਜਾਂ passkeys ਜੇ ਸੰਭਵ ਹੋ), magic links ਨੂੰ ਵਿਕਲਪਿਕ ਬੈਕਅੱਪ ਵਜੋਂ ਰੱਖੋ.
ਬਿੱਲਿੰਗ تبدਲੀਆਂ, ਐਕਸਪੋਰਟ, ਅਤੇ invites stakes ਵੱਧਾਉਂਦੇ ਹਨ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ SSO ਵਰਗੇ ਸਟੈਂਡਰਡ ਨਿਯੰਤਰਣਾਂ ਦੀ ਉਮੀਦ ਰੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਚਾਹੁੰਦੀਆਂ ਹਨ ਕਿ ਲਾਗਿਨ ਈਮੇਲ ਧੀਮਾ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰੇ। ਆਮ ਫੇਲ-ਮੋਡ ਕਮਜ਼ੋਰ recovery ਹੈ: “ਮੈਂ ਲਾਗਿਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਮੈਨੂੰ ਰੀਸੈਟ ਕਰੋ” ਜਿਹੇ ਸਪੋਰਟ ਬੇਨਤੀਆਂ ਇੱਕ impersonation ਰਾਹ ਬਣ ਸਕਦੀਆਂ ਹਨ ਜੇ ਤੁਸੀਂ ਠੀਕ ਤਸਦੀਕ ਨਾ ਕਰੋ।
ਦ੍ਰਿਸ਼ C: ਇੱਕ ਅੰਦਰੂਨੀ ਐਡਮਿਨ ਟੂਲ ਜਿਸਦੇ ਪਾਸ ਤਾਕਤਵਰ ਅਧਿਕਾਰ ਹਨ
ਡਿਫ਼ਾਲਟ: SSO ਨਾਲ ਮਜ਼ਬੂਤ MFA ਲਾਗੂ, ਜਾਂ passwords ਨਾਲ ਮਜ਼ਬੂਤ ਦੂਜਾ ਫੈਕਟਰ.
ਇੱਕ ਖਾਤਾ ਡੇਟਾ, ਅਧਿਕਾਰ, ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸੈਟਿੰਗਾਂ ਬਦਲ ਸਕਦਾ ਹੈ। ਸੁਝਾਅ ਇਹ ਹੈ ਕਿ ਸੁਵਿਧਾ ਮਹੱਤਵਪੂਰਣ ਹੈ, ਪਰ ਸੁਰੱਖਿਆ ਔਰ ਵੀ ਮਹੱਤਵਪੂਰਣ। ਆਮ ਫੇਲ-ਮੋਡ ਇਹ ਹੈ ਕਿ ਕੋਈ ਕਿਸੇ ਦੀ ਮਦਦ ਲਈ “ਲਾਗਿਨ” ਈਮੇਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਮੈਲਬਾਕਸ ਬਾਅਦ ਵਿਚ ਸੰਕ੍ਰਮਿਤ ਹੋ ਜਾਂਦਾ ਹੈ।
ਸਧਾਰਨ ਨਿਯਮ: ਘੱਟ-ਖਤਰਾ ਘੱਟ ਕਦਮਾਂ ਨੂੰ ਹਮਾਇਤ ਕਰਦਾ ਹੈ, ਉੱਚ-ਖਤਰਾ ਮਜ਼ਬੂਤ ਪਛਾਣ ਅਤੇ ਈਮੇਲ ਨਿਰਭਰਤਾ ਘੱਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡਾ ਫੰਸ ਇਹ ਹੈ ਕਿ ਲਾਗਿਨ ਨੂੰ صرف UI ਚੋਣ ਸਮਝ ਲਿਆ ਜਾਵੇ ਬਜਾਏ ਇਸਦੇ ਕਿ ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਖਤਰੇ ਵਾਲਾ ਚੋਣ ਹੈ।
ਈਮੇਲ ਹਰ ਵੇਲੇ ਤੁਰੰਤ ਨਹੀਂ ਹੁੰਦੀ। ਸੁਨੇਹੇ ਦੇਰੀ, spam ਵਿੱਚ ਫਸ ਜਾਣਾ, ਕਾਰਪੋਰੇਟ ਗੇਟਵੇਜ਼ ਦੁਆਰਾ ਬ੍ਲਾਕ ਹੋਣਾ, ਜਾਂ ਬਰਸਟ ਦੌਰਾਨ throttle ਹੋਣਾ ਆਮ ਗੱਲ ਹੈ (ਜਿਵੇਂ ਲਾਂਚ ਸਮੇਂ)। ਜੇ ਤੁਹਾਡੀ ਐਪ ਅਸਮਰਥ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦ ਈਮੇਲ ਦੇਰੀ ਨਾਲ ਆਵੇ, ਤਾਂ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਣਗੇ, ਨਾ ਕਿ ਆਪਣੇ ਇਨਬੌਕਸ ਨੂੰ। "ਈਮੇਲ ਨਹੀਂ ਆਈ" ਨੂੰ ਇੱਕ ਆਮ ਰਸਤਾ ਜ਼ਰੂਰ ਸਮਝੋ, edge case ਨਹੀਂ।
Magic links ਜਦ sessions ਬਹੁਤ ਲੰਬੇ ਹੋਣ ਅਤੇ ਡਿਵਾਈਸ ਕੰਟਰੋਲ ਕੀਤੇ ਨਾ ਜਾਣ ਤਾਂ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਕ ਗਲਤ ਕਲਿੱਕ ਕਿਸੇ ਸਾਂਝੇ ਕੰਪਿਊਟਰ 'ਤੇ ਇੱਕ ਚੁਪ-ਚੁਪ takeover ਬਣ ਸਕਦੀ ਹੈ ਜੇ ਸੈਸ਼ਨ ਹਫ਼ਤਿਆਂ ਤੱਕ ਮੌਜੂਦ ਰਹੇ। ਸੈਸ਼ਨ ਮਿਆਦ ਸੀਮਤ ਕਰੋ, active devices ਦਿਖਾਓ, ਅਤੇ “sign out everywhere” ਆਸਾਨ ਬਣਾਓ।
ਪਾਸਵਰਡ ਉਲਟ-ਦਿਸ਼ਾ ਵਿੱਚ fail ਹੁੰਦੇ ਹਨ: ਬਹੁਤ ਆਸਾਨ reset flows abuse ਨੂੰ ਬੁਲੰਦਾ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਬਹੁਤ ਕਠੋਰ reset flows lockouts ਬਣਾਉਂਦੇ ਹਨ। ਜੇ recovery ਪੰਜ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਪਰਫੈਕਟ ਟਾਇਪਿੰਗ ਲੈਂਦੀ ਹੈ, ਲੋਕ give up ਕਰਕੇ duplicate accounts ਬਣਾਉਣਗੇ।
ਉੱਚ-ਪ੍ਰਭਾਵ ਕਾਰਜਾਂ ਨੂੰ ਵਧੀਆਂ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਲਾਗਿਨ ਤਰੀਕੇ ਨੂੰ ਚੁਣੋ। ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ exports, payouts, admin role changes, billing updates, ਅਤੇ custom domain ਬਦਲਾਅ ਸ਼ਾਮਲ ਹਨ। ਉਹ ਕਾਰਵਾਈਆਂ ਜਿਹੜੀਆਂ ਐਪਾਂ ਨੂੰ deploy ਕਰਨ ਜਾਂ source code export ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ (ਜਿਵੇਂ Koder.ai) ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਤਾਜ਼ਾ ਜਾਂਚ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ।
ਕੁਝ ਸੁਧਾਰ ਜਿਹੜੇ ਜ਼ਿਆਦਾਤਰ ਦਰਦ ਰੋਕਦੇ ਹਨ:
"ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ" ਵਰਗੇ ਢਿੱਗੇ ਸੁਨੇਹਿਆਂ ਤੋਂ ਬਚੋ। ਜੇ ਲਿੰਕ expire ਹੋ ਗਿਆ ਤਾਂ ਉਹ ਦੱਸੋ। ਜੇ ਪਾਸਵਰਡ ਗਲਤ ਹੈ ਤਾਂ ਇਹ ਦੱਸੋ। ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਦਿਓ।
ਡਿਫ਼ਾਲਟ ਨੂੰ ਫੈਸਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ:
ਲਾਂਚ ਤੋਂ ਬਾਅਦ, "ਚੱਲ ਰਿਹਾ ਹੈ" ਦਾ ਮਤਲਬ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਹਫਤੇਵਾਰ ਇਸਨੂੰ ਟ੍ਰੈਕ ਕਰੋ: ਲਾਗਿਨ ਡ੍ਰਾਪ-ਆਫ (ਸ਼ੁਰੂ ਕੀਤੇ vs ਪੂਰੇ), ਸਨਦੇਸ਼ ਤੇ ਪਹਿਲੀ ਸਫਲਤਾ ਤੱਕ ਦਾ ਸਮਾਂ, ਅਤੇ "ਲਾਗਿਨ ਨਹੀਂ ਹੋ ਰਹਾ" ਜਾਂ "ਈਮੇਲ ਨਹੀਂ ਆਈ" ਵਾਸਤੇ ਸਪੋਰਟ ਵਾਲੀ ਪ੍ਰਮਾਣਗੀ।
ਜੇ ਤੁਸੀਂ ਇਹ ਫਲੋ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ Planning Mode ਵਿੱਚ ਪੂਰੀ ਯਾਤਰਾ (ਲਾਗਿਨ, ਰਿਕਵਰੀ, ਲਾਗਆਊਟ, ਡਿਵਾਈਸ ਬਦਲ) ਨਕਸ਼ਾ ਕਰੋ। snapshots ਅਤੇ rollback ਇਹ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਲਾਗਿਨ UX 'ਤੇ ਤਬਦੀਲੀ ਕਰਨ ਸਮੇਂ ਹਰ ਬਦਲਾਅ ਨੂੰ ਖਤਰਨਾਕ ਡਿਪਲੋਏ ਨਾ ਬਣਾਉ।
ਜਦੋਂ ਖਾਤੇ ਦਾ ਪ੍ਰਭਾਵ ਘੱਟ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਪਹਿਲੀ ਲਾਗਇਨ ਤੇ ਤੇਜ਼ੀ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਉਦਾਹਰਨ ਲਈ default ਨੂੰ magic links ਰੱਖੋ। ਜਦੋਂ ਖਾਤੇ ਬਿੱਲਿੰਗ, ਰੋਲ, ਐਕਸਪੋਰਟ ਜਾਂ ਹੋਰ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ ਤਾਂ passwords (ਆਈਡિયਲ ਤੌਰ 'ਤੇ ਵਿਵਿਕਲ MFA ਨਾਲ) ਨੂੰ ਡੀਫ਼ਾਲਟ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ enterprise ਗਾਹਕਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਤਾਂ SSO ਲਈ ਤਿਆਰੀ ਕਰੋ ਭਾਵੇਂ ਤੁਸੀਂ ਕਿਸ ਡੀਫ਼ਾਲਟ ਨੂੰ ਚੁਣੋ।
ਹਾਂ, ਪਰ ਸਿਰਫ ਜੇ ਲਿੰਕ single-use ਹੋਵੇ, ਜਲਦੀ expire ਹੋਵੇ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਵਾਧੂ ਚੈੱਕ ਲਗਾਇਆ ਹੋਵੇ। ਸੱਚੀ ਸੁਰੱਖਿਆ ਦੀ ਹੱਦ ਹੁਣ ਯੂਜ਼ਰ ਦੇ ਈਮੇਲ ਇਨਬੌਕਸ ਅਤੇ ਉਨ੍ਹਾਂ ਡਿਵਾයිਸਾਂ ਦੇ ਬਰਾਬਰ ਹੋ ਜਾਂਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਐਕਸੈੱਸ ਕਰ ਸਕਦੇ ਹਨ — ਤੁਸੀਂ ਖਤਰੇ ਨੂੰ ਬਦਲ ਰਹੇ ਹੋ, ਹਟਾ ਨਹੀਂ ਰਹੇ। ਸੈਸ਼ਨ ਕੰਟਰੋਲ ਅਤੇ step-up verification ਨਾਲ ਜੋੜੋ।
ਡਿਲਿਵਰੇਬਿਲਟੀ ਨੂੰ ਆਪਣੇ ਲਾਗਿਨ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਮੰਨੋ, ਨਾ ਕਿ ਵੱਖਰਾ “ਈਮੇਲ ਸਮੱਸਿਆ”। ਛੋਟੇ-ਸਮੀਤ ਲਿੰਕ ਵਰਤੋ, ਸਪਸ਼ਟ “ਲਿੰਕ ਮਿਆਦ-ਪਾਰ ਹੋ ਗਿਆ” ਵਾਲੀ ਸੁਨੇਹਾ ਦਿਓ, ਅਤੇ ਐਸਾ ਫਲੋ ਬਣਾਓ ਜੋ ਵੱਖਰੇ ਡਿਵਾਈਸ 'ਤੇ ਈਮੇਲ ਖੋਲ੍ਹਣ 'ਤੇ ਖਤਮ ਨਾ ਹੋ ਜਾਏ। ਇਕ fallback ਜਿਵੇਂ one-time code ਜਾਂ ਹੋਰ ਸਾਈਨ-ਇਨ ਢੰਗ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ “ਈਮੇਲ ਨਹੀਂ ਆਈ” ਹਰ ਲਾਗਇਨ ਨੂੰ ਰੋਕਣ ਨਾ ਦੇਵੇ।
ਇੱਕੋ ਹੀ ਇਨਬੌਕਸ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। ਇੱਕ ਵਿਆਹਤ ਡਿਫ਼ਾਲਟ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬੈਕਅੱਪ ਮੈਥਡ ਐਡ ਕਰਨ ਦਿਓ — ਉਦਾਹਰਨ ਲਈ authenticator ਐਪ, recovery ਕੋਡ, ਜਾਂ ਦੂਜਾ verified ਈਮੇਲ। ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਖਾਤਿਆਂ ਲਈ login ਈਮੇਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਧੂ ਸਤ੍ਹਾ ਤਸਦੀਕ ਲੋ ਤਾਂ ਜੋ ਹਮਲਾਵਰ ਭਵਿੱਖੀ ਐਕਸੈੱਸ ਨੂੰ ਰੀ-ਰੂਟ ਨਾ ਕਰ ਸਕੇ।
ਲਾਗਇਨ ਪੇਜ ਨੂੰ autofill ਅਤੇ password managers ਲਈ ਅਨੁਕੂਲ ਬਣਾਓ, ਅਜਿਹੀਆਂ ਨੀਤੀਆਂ ਤੋਂ ਬਚੋ ਜੋ ਅਜੀਬ ਫਾਰਮੈਟ ਮਜ਼ਬੂਰ ਕਰਦੀਆਂ ਹਨ। ਲੰਬੇ passphrases ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, paste ਨੂੰ ਰੋਕੋ ਨਾ, ਕਿਉਂਕਿ ਇਹ ਮੈਨੇਜਰਾਂ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਕਮਜ਼ੋਰ ਚੋਣਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ। ਵਿਕਲਪਿਕ MFA ਅਤੇ ਤੋਂ-ਮੀਲੇ ਰੇਟ-ਲਿਮਟਿੰਗ ਜੋੜੋ ਤਾਂ ਕਿ phishing ਅਤੇ credential stuffing ਵਰਗੀਆਂ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਘਟ ਜਾਣ।
MFA ਸਭ ਤੋਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਨਵੇਂ ਡਿਵਾਈਸਾਂ, ਖਾਤੇ ਬਦਲਾਅ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ — ਸਿਰਫ਼ ਆਮ ਲਾਗਿਨ 'ਤੇ ਨਹੀਂ। ਉਦਾਹਰਨ ਲਈ, ਸਧਾਰਨ ਸਾਈਨ-ਇਨ ਦੀ ਆਗਿਆ ਦਿਓ, ਫਿਰ exports, billing changes, ਜਾਂ role edits ਤੋਂ ਪਹਿਲਾਂ ਤਾਜ਼ਾ ਦੂਜਾ ਫੈਕਟਰ ਮੰਗੋ। ਇਸ ਨਾਲ ਰੋਜ਼ਾਨਾ ਰੁਕਾਵਟ ਘੱਟ ਰਹਿੰਦੀ ਹੈ ਪਰ ਚੋਰੀ ਹੋਏ ਸੈਸ਼ਨ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਉੱਚ-ਰਿਸਕ ਰੋਲਾਂ ਲਈ ਸੈਸ਼ਨ ਸੰਗਲਤ ਰੱਖੋ ਅਤੇ ਐਕਟਿਵ ਸੈਸ਼ਨਾਂ ਨੂੰ ਦਿਖਾਓ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਕੁਝ ਗਲਤ ਵੇਖ ਸਕਣ। ਇੱਕ ਸਪਸ਼ਟ “ਸਭ ਥਾਂ ਤੋਂ ਸਾਈਨ ਆਊਟ” ਵਿਕਲਪ ਦਿਓ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਨੂੰ ਫਿਰ ਤੋਂ ਜਾਂਚੋ, ਭਾਵੇਂ ਸੈਸ਼ਨ ਅਜੇ ਵੀ ਵੈਧ ਹੋਵੇ। ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਚੋਰੀ ਹੋਏ ਲੈਪਟਾਪ ਜਾਂ ਭੁੱਲਿਆ ਹੋਇਆ ਲਾਗਿਨ ਕਿੰਨਾ ਸਮਾਂ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ, ਉਸ ਨੂੰ ਸੀਮਿਤ ਕੀਤਾ ਜਾਵੇ।
ਸ਼ੇਅਰ ਕੀਤੇ ਡਿਵਾਈਸ ਦੋਹਾਂ ਤਰੀਕਿਆਂ ਲਈ ਖਤਰਾ ਵਧਾਉਂਦੇ ਹਨ, ਪਰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ। ਜੇ ਯੂਜ਼ਰ ਦਾ ਈਮੇਲ ਉਸ ਡਿਵਾਈਸ 'ਤੇ ਖੁੱਲ੍ਹਾ ਹੈ ਤਾਂ magic links ਖਤਰਨਾਕ ਹਨ, ਜਦਕਿ ਬ੍ਰਾਊਜ਼ਰ ਪਾਸਵਰਡ ਸੇਵ ਕਰ ਲਏ ਤਾਂ passwords ਖਤਰਨਾਕ। ਸਪਸ਼ਟ ਸਾਇਨ-ਆਊਟ ਦਿਖਾਓ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਚਿੱਪਕਣ ਵਾਲੇ “remember me” ਤੋਂ ਬਚੋ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ چیزਾਂ ਤੋਂ ਪਹਿਲਾਂ step-up verification ਉਪਯੋਗ ਕਰੋ।
ਐਂਟਰਪ ਰਾਈਜ਼ ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ-ਠਾਕ ਲਾਗਿਨ ਸਕ੍ਰੀਨ ਤੋਂ ਘੱਟ ਅਤੇ ਕੇਂਦਰਤ ਨਿਯੰਤਰਣ ਤੋਂ ਵੱਧ ਚਿੰਤਿਤ ਹੁੰਦੇ ਹਨ। SSO, ਨਜ਼ਮੀ MFA, ਆਡਿਟ ਲਾਗ, ਰੋਲ-ਅਧਾਰਤ ਐਕਸੈੱਸ, ਅਤੇ ਤੇਜ਼ offboarding ਦੀ ਉਮੀਦ ਕਰੋ ਤਾਂ ਕਿ ਖਾਤਿਆਂ ਨੂੰ ਜਲਦੀ ਅਕਸੇਸ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਜੇ ਤੁਸੀਂ ਇਹ ਮੰਗਾਂ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਲਾਗਿਨ ਤਰੀਕਾ ਮੁਤਲਕ ਮਹੱਤਵ ਨਹੀਂ ਰੱਖੇਗਾ ਕਿਉਂਕਿ procurement ਅਪਨਾਏਗੀ।
ਸ਼ੁਰੂ-ਵਿਰੁੱਧ ਪੂਰਾ ਲਾਗਇਨ (started-vs-completed), ਪਹਿਲੀ ਸਫਲ ਲਾਗਇਨ ਤੱਕ ਦਾ ਸਮਾਂ, ਅਤੇ ਕਿੰਨੀ ਵਾਰ ਯੂਜ਼ਰ ਦੂਜੀ ਈਮੇਲ ਜਾਂ ਰੀਸੈਟ ਮੰਗਦੇ ਹਨ — ਇਹ ਸਭ ਟਰੈਕ ਕਰੋ। “ਈਮੇਲ ਨਹੀਂ ਆਈ” ਅਤੇ “ਲਾਗਇਨ ਨਹੀਂ ਹੋ ਰਿਹਾ” ਜਿਹੇ ਸਪੋਰਟ ਟਿਕਟਾਂ ਨੂੰ ਵੇਖੋ, ਅਤੇ ਅਟੈਕ ਪਕੜਨ ਲਈ ਫੇਲ ਹੋਏ ਉੱਦਮਾਂ ਵਿੱਚ ਅਚਾਨਕ ਵਾਧਾ ਨਿਗਰਾਨੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਵਿੱਚ ਪੂਰਾ ਯਾਤਰਾ ਨਕਸ਼ਾ ਬਣਾਓ ਅਤੇ metrics ਤੋਂ ਪਤਾ ਲੱਗਣ 'ਤੇ snapshots/rollback ਨਾਲ ਬਦਲਾਅ ਕਵਰੇਜ ਕਰੋ।