ਉਹ ਸਭ ਕੁਝ ਜੋ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਰਨ ਬਾਰੇ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਭਾਗ 1

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

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

ਪਾਸਵਰਡ ਸਟੋਰੇਜ: ਹੈਸ਼ਿੰਗ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ (ਹਾਸ!) ਸਾਦਾ ਟੈਕਸਟ

ਅਸੀਂ ਭੁੱਲੇ ਹੋਏ ਪਾਸਵਰਡਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਚਰਚਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਪਾਸਵਰਡ ਡੇਟਾਬੇਸ ਵਿੱਚ ਤਿੰਨ ਮੁੱਖ ਕਿਸਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

1. ਸਧਾਰਨ ਪਾਠ. ਇੱਥੇ ਇੱਕ ਪਾਸਵਰਡ ਕਾਲਮ ਹੈ, ਜੋ ਕਿ ਪਲੇਨ ਟੈਕਸਟ ਫਾਰਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
2. ਐਨਕ੍ਰਿਪਟਡ। ਆਮ ਤੌਰ 'ਤੇ ਸਿਮਟ੍ਰਿਕ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ (ਇੱਕ ਕੁੰਜੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਦੋਵਾਂ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ), ਅਤੇ ਇਨਕ੍ਰਿਪਟਡ ਪਾਸਵਰਡ ਵੀ ਉਸੇ ਕਾਲਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
3. ਹੈਸ਼ਡ. ਇੱਕ ਤਰਫਾ ਪ੍ਰਕਿਰਿਆ (ਪਾਸਵਰਡ ਨੂੰ ਹੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਡੀਹੈਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ); ਪਾਸਵਰਡ, ਮੈਂ ਉਮੀਦ ਕਰਨਾ ਚਾਹਾਂਗਾ, ਇੱਕ ਲੂਣ ਦੇ ਬਾਅਦ, ਅਤੇ ਹਰ ਇੱਕ ਆਪਣੇ ਹੀ ਕਾਲਮ ਵਿੱਚ ਹੈ.

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

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

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

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

ਸਾਵਧਾਨ

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

ਹਮੇਸ਼ਾ ਆਪਣਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰੋ ਕਦੇ ਨਹੀਂ ਉਸਨੂੰ ਯਾਦ ਨਾ ਕਰੋ

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

ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ "ਰੀਮਾਈਂਡਰ" ਸ਼ਬਦ (ਅਕਸਰ) ਬੋਲਚਾਲ ਦੇ ਅਰਥਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਉਪਭੋਗਤਾ ਨੂੰ ਦੁਬਾਰਾ ਔਨਲਾਈਨ ਹੋਣ ਵਿੱਚ ਮਦਦ ਕਰੋ. ਕਿਉਂਕਿ ਸਾਨੂੰ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਲਈ ਦੋ ਕਾਰਨ ਹਨ ਕਿ ਇੱਕ ਰੀਮਾਈਂਡਰ (ਜਿਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਉਹਨਾਂ ਦਾ ਪਾਸਵਰਡ ਭੇਜਣਾ) ਉਚਿਤ ਨਹੀਂ ਹੈ:

1. ਈਮੇਲ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਚੈਨਲ ਹੈ। ਜਿਸ ਤਰ੍ਹਾਂ ਅਸੀਂ HTTP 'ਤੇ ਕੁਝ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਨਹੀਂ ਭੇਜਾਂਗੇ (ਅਸੀਂ HTTPS ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ), ਸਾਨੂੰ ਈਮੇਲ 'ਤੇ ਕੁਝ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਨਹੀਂ ਭੇਜਣਾ ਚਾਹੀਦਾ ਕਿਉਂਕਿ ਇਸਦੀ ਆਵਾਜਾਈ ਪਰਤ ਅਸੁਰੱਖਿਅਤ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਭੇਜਣ ਨਾਲੋਂ ਬਹੁਤ ਮਾੜਾ ਹੈ, ਕਿਉਂਕਿ ਮੇਲ ਅਕਸਰ ਸਟੋਰੇਜ ਡਿਵਾਈਸ 'ਤੇ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਪਹੁੰਚਯੋਗ, ਅੱਗੇ ਭੇਜੀ ਅਤੇ ਵੰਡੀ ਜਾਂਦੀ ਹੈ, ਮਾਲਵੇਅਰ ਤੱਕ ਪਹੁੰਚਯੋਗ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਰ ਵੀ। ਗੈਰ-ਇਨਕ੍ਰਿਪਟਡ ਈਮੇਲ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸੁਰੱਖਿਅਤ ਚੈਨਲ ਹੈ।
2. ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਪਾਸਵਰਡ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਸਟੋਰੇਜ 'ਤੇ ਪਿਛਲੇ ਭਾਗ ਨੂੰ ਮੁੜ-ਪੜ੍ਹੋ - ਤੁਹਾਡੇ ਕੋਲ ਪਾਸਵਰਡ ਦੀ ਇੱਕ ਹੈਸ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਇੱਕ ਚੰਗੇ ਮਜ਼ਬੂਤ ​​ਲੂਣ ਦੇ ਨਾਲ), ਮਤਲਬ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਪਾਸਵਰਡ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਡਾਕ ਰਾਹੀਂ ਭੇਜਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮੈਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਦਿਓ usoutdoor.com: ਇੱਥੇ ਇੱਕ ਆਮ ਲੌਗਇਨ ਪੰਨਾ ਹੈ:

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਪਹਿਲੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਲੌਗਇਨ ਪੰਨਾ HTTPS 'ਤੇ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਾਈਟ ਤੁਹਾਨੂੰ ਪਾਸਵਰਡ ("ਪਾਸਵਰਡ ਭੇਜੋ") ਭੇਜਣ ਲਈ ਵੀ ਪੁੱਛਦੀ ਹੈ। ਇਹ ਉੱਪਰ ਦੱਸੇ ਗਏ ਸ਼ਬਦ ਦੀ ਬੋਲਚਾਲ ਦੀ ਵਰਤੋਂ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਆਓ ਇਸਨੂੰ ਇੱਕ ਕਦਮ ਹੋਰ ਅੱਗੇ ਲੈ ਕੇ ਵੇਖੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ:

ਇਹ ਬਦਕਿਸਮਤੀ ਨਾਲ, ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਲੱਗਦਾ; ਅਤੇ ਇੱਕ ਈਮੇਲ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ ਸਮੱਸਿਆ ਹੈ:

ਇਹ ਸਾਨੂੰ usoutdoor.com ਦੇ ਦੋ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਦੱਸਦਾ ਹੈ:

1. ਸਾਈਟ ਪਾਸਵਰਡ ਹੈਸ਼ ਨਹੀਂ ਕਰਦੀ। ਸਭ ਤੋਂ ਵਧੀਆ, ਉਹ ਐਨਕ੍ਰਿਪਟਡ ਹਨ, ਪਰ ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਉਹ ਸਾਦੇ ਟੈਕਸਟ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਨ; ਅਸੀਂ ਇਸਦੇ ਉਲਟ ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਦੇਖਦੇ.
2. ਸਾਈਟ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਚੈਨਲ 'ਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪਾਸਵਰਡ ਭੇਜਦੀ ਹੈ (ਅਸੀਂ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਬਾਰ ਬਾਰ ਵਰਤ ਸਕਦੇ ਹਾਂ)।

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

ਉਪਭੋਗਤਾ ਨਾਮਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣਾ ਅਤੇ ਅਗਿਆਤਤਾ 'ਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਦ੍ਰਿਸ਼ਟੀਗਤ ਰੂਪ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਸਮੱਸਿਆ:

ਕੀ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ? ਸੁਨੇਹੇ ਵੱਲ ਧਿਆਨ ਦਿਓ "ਇਸ ਈਮੇਲ ਪਤੇ ਨਾਲ ਕੋਈ ਉਪਭੋਗਤਾ ਰਜਿਸਟਰਡ ਨਹੀਂ ਹੈ।" ਸਮੱਸਿਆ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜੇਕਰ ਅਜਿਹੀ ਸਾਈਟ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਉਪਲਬਧਤਾ ਅਜਿਹੇ ਈਮੇਲ ਪਤੇ ਨਾਲ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ। ਬਿੰਗੋ - ਤੁਸੀਂ ਹੁਣੇ ਹੀ ਆਪਣੇ ਪਤੀ/ਬੌਸ/ਗੁਆਂਢੀ ਦੇ ਪੋਰਨ ਫੈਟਿਸ਼ ਦੀ ਖੋਜ ਕੀਤੀ ਹੈ!

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

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

ਬਦਲ ਕੀ ਹੈ? ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ, ਅਤੇ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ Entropay:

ਇੱਥੇ Entropay ਆਪਣੇ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਈਮੇਲ ਪਤੇ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਬਿਲਕੁਲ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਜੋ ਇਸ ਪਤੇ ਦਾ ਮਾਲਕ ਨਹੀਂ ਹੈ... ਜੇ ਤੁਹਾਨੂੰ ਆਪਣੇ ਇਹ ਪਤਾ ਅਤੇ ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਫਿਰ ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਇੱਕ ਈਮੇਲ ਪ੍ਰਾਪਤ ਹੋਵੇਗੀ:

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

Entropay ਦੁਆਰਾ ਚੁਣੇ ਗਏ ਹੱਲ ਦੀ ਸੂਖਮਤਾ ਇਹ ਹੈ ਕਿ ਪਛਾਣ ਦੀ ਤਸਦੀਕ ਇਸਦੇ ਅਨੁਸਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਈ - ਮੇਲ ਕਿਸੇ ਵੀ ਔਨਲਾਈਨ ਤਸਦੀਕ ਤੋਂ ਪਹਿਲਾਂ. ਕੁਝ ਸਾਈਟਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਸਵਾਲ ਦਾ ਜਵਾਬ ਪੁੱਛਦੀਆਂ ਹਨ (ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ) ਨੂੰ ਰੀਸੈਟ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ; ਹਾਲਾਂਕਿ, ਇਸ ਨਾਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੀ ਪਛਾਣ (ਈਮੇਲ ਜਾਂ ਉਪਭੋਗਤਾ ਨਾਮ) ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਗਿਆਤ ਉਪਭੋਗਤਾ ਦੇ ਖਾਤੇ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਪ੍ਰਗਟ ਕੀਤੇ ਬਿਨਾਂ ਅਨੁਭਵੀ ਜਵਾਬ ਦੇਣਾ ਲਗਭਗ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।

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

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

ਰੀਸੈਟ ਪਾਸਵਰਡ ਬਨਾਮ ਰੀਸੈਟ URL ਭੇਜਣਾ

ਅਗਲਾ ਸੰਕਲਪ ਜਿਸ 'ਤੇ ਸਾਨੂੰ ਚਰਚਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਉਹ ਹੈ ਆਪਣਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ। ਇੱਥੇ ਦੋ ਪ੍ਰਸਿੱਧ ਹੱਲ ਹਨ:

1. ਸਰਵਰ 'ਤੇ ਨਵਾਂ ਪਾਸਵਰਡ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਈਮੇਲ ਰਾਹੀਂ ਭੇਜਣਾ
2. ਰੀਸੈਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਵਿਲੱਖਣ URL ਦੇ ਨਾਲ ਇੱਕ ਈਮੇਲ ਭੇਜੋ

ਦੇ ਬਾਵਜੂਦ ਬਹੁਤ ਸਾਰੇ ਗਾਈਡ, ਪਹਿਲਾ ਬਿੰਦੂ ਕਦੇ ਨਹੀਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨਾਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉੱਥੇ ਹੈ ਸਟੋਰ ਕੀਤਾ ਪਾਸਵਰਡ, ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹੋ; ਇਹ ਇੱਕ ਅਸੁਰੱਖਿਅਤ ਚੈਨਲ ਉੱਤੇ ਭੇਜਿਆ ਗਿਆ ਸੀ ਅਤੇ ਤੁਹਾਡੇ ਇਨਬਾਕਸ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਸੰਭਾਵਨਾਵਾਂ ਹਨ ਕਿ ਇਨਬਾਕਸ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਅਤੇ ਈਮੇਲ ਕਲਾਇੰਟ ਵਿੱਚ ਸਿੰਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਨਾਲ ਹੀ ਉਹ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਲਈ ਵੈਬ ਈਮੇਲ ਸੇਵਾ ਵਿੱਚ ਔਨਲਾਈਨ ਸਟੋਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇੱਕ ਮੇਲਬਾਕਸ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਟੋਰੇਜ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਾਧਨ ਨਹੀਂ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ.

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

ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਰੀਸੈਟ URL ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਡਾ ਮਤਲਬ ਇੱਕ ਵੈਬਸਾਈਟ ਦਾ ਪਤਾ ਹੈ ਜੋ ਹੈ ਰੀਸੈਟ ਪ੍ਰਕਿਰਿਆ ਦੇ ਇਸ ਖਾਸ ਕੇਸ ਲਈ ਵਿਲੱਖਣ. ਬੇਸ਼ੱਕ, ਇਹ ਬੇਤਰਤੀਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਆਸਾਨ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਖਾਤੇ ਦੇ ਕੋਈ ਬਾਹਰੀ ਲਿੰਕ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਇਸਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਰੀਸੈਟ URL ਨੂੰ ਸਿਰਫ਼ "Reset/?username=JohnSmith" ਵਰਗਾ ਮਾਰਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਸੀਂ ਇੱਕ ਵਿਲੱਖਣ ਟੋਕਨ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ ਇੱਕ ਰੀਸੈਟ URL ਦੇ ਰੂਪ ਵਿੱਚ ਮੇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਪਭੋਗਤਾ ਦੇ ਖਾਤੇ ਦੇ ਸਰਵਰ ਰਿਕਾਰਡ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਖਾਤਾ ਮਾਲਕ ਅਸਲ ਵਿੱਚ ਉਹੀ ਵਿਅਕਤੀ ਹੈ ਜੋ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਟੋਕਨ "3ce7854015cd38c862cb9e14a1ae552b" ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਰੀਸੈਟ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੀ ID ਅਤੇ ਟੋਕਨ ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ)। ਜਦੋਂ ਈਮੇਲ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਸ ਵਿੱਚ ਇੱਕ URL ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, ਅਤੇ ਜਦੋਂ ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੰਨਾ ਟੋਕਨ ਦੀ ਮੌਜੂਦਗੀ ਲਈ ਪੁੱਛਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਉਪਭੋਗਤਾ ਦੀ ਜਾਣਕਾਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪਾਸਵਰਡ।

ਬੇਸ਼ੱਕ, ਕਿਉਂਕਿ ਉਪਰੋਕਤ ਪ੍ਰਕਿਰਿਆ (ਉਮੀਦ ਹੈ) ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਨਵਾਂ ਪਾਸਵਰਡ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ URL HTTPS 'ਤੇ ਲੋਡ ਕੀਤਾ ਗਿਆ ਹੈ। ਨਹੀਂ, ਇਸਨੂੰ HTTPS ਉੱਤੇ ਇੱਕ POST ਬੇਨਤੀ ਦੇ ਨਾਲ ਭੇਜਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਇਸ ਟੋਕਨ URL ਨੂੰ ਟਰਾਂਸਪੋਰਟ ਲੇਅਰ ਸੁਰੱਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਨਵੇਂ ਪਾਸਵਰਡ ਫਾਰਮ 'ਤੇ ਹਮਲਾ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ MITM ਅਤੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਪਾਸਵਰਡ ਇੱਕ ਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

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

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

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

ਕੈਪਟਚਾ ਦੀ ਭੂਮਿਕਾ

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

ਬੇਸ਼ੱਕ, ਕੈਪਟਚਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੰਪੂਰਨ ਨਹੀਂ ਹੈ; ਇਸਦੇ ਸੌਫਟਵੇਅਰ "ਹੈਕਿੰਗ" ਅਤੇ ਲੋੜੀਂਦੀ ਸਫਲਤਾ ਦਰਾਂ (60-70%) ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਬਾਰੇ ਮੇਰੀ ਪੋਸਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਇੱਕ ਹੱਲ ਹੈ ਸਵੈਚਲਿਤ ਲੋਕਾਂ ਦੁਆਰਾ ਕੈਪਟਚਾ ਹੈਕਿੰਗ, ਜਿੱਥੇ ਤੁਸੀਂ ਹਰੇਕ ਕੈਪਟਚਾ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ 94% ਦੀ ਸਫਲਤਾ ਦਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਸੈਂਟ ਦੇ ਅੰਸ਼ਾਂ ਦਾ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹੋ। ਭਾਵ, ਇਹ ਕਮਜ਼ੋਰ ਹੈ, ਪਰ ਇਹ (ਥੋੜਾ ਜਿਹਾ) ਦਾਖਲੇ ਲਈ ਰੁਕਾਵਟ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ.

ਆਉ PayPal ਉਦਾਹਰਨ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ:

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਰੀਸੈਟ ਪ੍ਰਕਿਰਿਆ ਉਦੋਂ ਤੱਕ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦੀ ਜਦੋਂ ਤੱਕ ਕੈਪਟਚਾ ਹੱਲ ਨਹੀਂ ਹੋ ਜਾਂਦਾ, ਇਸ ਲਈ ਸਿਧਾਂਤਕ ਤੌਰ ਤੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨਾ ਅਸੰਭਵ ਹੈ। ਸਿਧਾਂਤ ਵਿੱਚ.

ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇਹ ਓਵਰਕਿਲ ਹੋਵੇਗਾ ਅਤੇ ਬਿਲਕੁਲ ਸਹੀ ਉਪਯੋਗਤਾ ਵਿੱਚ ਕਮੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ - ਲੋਕ ਕੈਪਟਚਾ ਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਹਨ! ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੈਪਟਚਾ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ ਜੇ ਲੋੜ ਹੋਵੇ। ਜੇ ਸੇਵਾ ਹਮਲੇ ਵਿੱਚ ਆਉਣੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ (ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਲੌਗਿੰਗ ਕੰਮ ਆਉਂਦੀ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ), ਤਾਂ ਕੈਪਟਚਾ ਜੋੜਨਾ ਸੌਖਾ ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਗੁਪਤ ਸਵਾਲ ਅਤੇ ਜਵਾਬ

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

ਵਾਸਤਵ ਵਿੱਚ, ਸਾਰਾਹ ਪਾਲਿਨ ਦੇ ਯਾਹੂ ਦੀ ਹੈਕਿੰਗ ਬਾਰੇ ਉਪਰੋਕਤ ਲਿੰਕ! ਦੋ ਉਦੇਸ਼ਾਂ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ; ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ (ਕੁਝ) ਈਮੇਲ ਖਾਤਿਆਂ ਨੂੰ ਹੈਕ ਕਰਨਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ, ਅਤੇ ਦੂਜਾ, ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਗਲਤ ਇਰਾਦੇ ਨਾਲ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਪਰ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ।

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

ਇਸ ਖਤਰੇ ਨੂੰ ਘਟਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਸੁਰੱਖਿਆ ਸਵਾਲ ਅਤੇ ਜਵਾਬ ਪੈਟਰਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੈ। ਕੋਈ ਸ਼ੱਕ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੈ: ਇੱਕ ਸਵਾਲ ਚੁਣੋ ਜਿਸਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਤੁਸੀਂ ਹੀ ਦੇ ਸਕਦੇ ਹੋ должны ਜਵਾਬ ਜਾਣੋ, ਅਤੇ ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਪੁੱਛਿਆ ਜਾਵੇਗਾ। ਇਹ ਵਿਸ਼ਵਾਸ ਜੋੜਦਾ ਹੈ ਕਿ ਰੀਸੈਟ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲਾ ਵਿਅਕਤੀ ਅਸਲ ਵਿੱਚ ਖਾਤਾ ਮਾਲਕ ਹੈ।

ਸਾਰਾਹ ਪਾਲਿਨ 'ਤੇ ਵਾਪਸ ਜਾਓ: ਗਲਤੀ ਇਹ ਸੀ ਕਿ ਉਸ ਦੇ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ/ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਆਸਾਨੀ ਨਾਲ ਲੱਭੇ ਜਾ ਸਕਦੇ ਸਨ। ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਤੁਸੀਂ ਅਜਿਹੀ ਮਹੱਤਵਪੂਰਨ ਜਨਤਕ ਸ਼ਖਸੀਅਤ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਮਾਂ ਦੇ ਪਹਿਲੇ ਨਾਮ, ਵਿਦਿਅਕ ਇਤਿਹਾਸ, ਜਾਂ ਕੋਈ ਅਤੀਤ ਵਿੱਚ ਕਿੱਥੇ ਰਹਿ ਸਕਦਾ ਹੈ, ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਹ ਸਭ ਕੁਝ ਗੁਪਤ ਨਹੀਂ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਸਦਾ ਜ਼ਿਆਦਾਤਰ ਲਗਭਗ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਦੁਆਰਾ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਸਾਰਾਹ ਨਾਲ ਅਜਿਹਾ ਹੋਇਆ:

ਹੈਕਰ ਡੇਵਿਡ ਕਰਨਲ ਨੇ ਪਾਲਿਨ ਦੇ ਪਿਛੋਕੜ ਬਾਰੇ ਵੇਰਵੇ ਲੱਭ ਕੇ, ਜਿਵੇਂ ਕਿ ਉਸਦੀ ਯੂਨੀਵਰਸਿਟੀ ਅਤੇ ਜਨਮ ਮਿਤੀ, ਅਤੇ ਫਿਰ Yahoo! ਦੀ ਭੁੱਲੇ ਹੋਏ ਪਾਸਵਰਡ ਰਿਕਵਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸਦੇ ਖਾਤੇ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ।

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

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

ਅਸਮਾਨ ਦਾ ਰੰਗ ਕਿਹੜਾ ਹੈ?

ਉਹ ਸਵਾਲ ਜੋ ਲੋਕਾਂ ਨੂੰ ਅਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦੇ ਹਨ ਜਦੋਂ ਇੱਕ ਸੁਰੱਖਿਆ ਸਵਾਲ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਵਿਅਕਤੀ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਾਲ ਸੈਂਟਰ ਵਿੱਚ):

ਕ੍ਰਿਸਮਸ 'ਤੇ ਮੈਂ ਕਿਸ ਨਾਲ ਸੌਂਦਾ ਸੀ?

ਜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮੂਰਖ ਸਵਾਲ:

ਤੁਸੀਂ "ਪਾਸਵਰਡ" ਕਿਵੇਂ ਲਿਖਦੇ ਹੋ?

ਜਦੋਂ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਤੋਂ ਬਚਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ! ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਸਵਾਲ ਨੂੰ ਸਾਈਟ ਦੁਆਰਾ ਖੁਦ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਬਿਹਤਰ ਅਜੇ ਤੱਕ, ਪੁੱਛਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਲੜੀ ਸੁਰੱਖਿਆ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਉਪਭੋਗਤਾ ਚੁਣ ਸਕਦਾ ਹੈ। ਅਤੇ ਇਹ ਚੁਣਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ один; ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਦੋ ਜਾਂ ਵੱਧ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦੀ ਚੋਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਖਾਤਾ ਰਜਿਸਟਰੇਸ਼ਨ ਦੇ ਸਮੇਂ, ਜੋ ਫਿਰ ਇੱਕ ਦੂਜੇ ਪਛਾਣ ਚੈਨਲ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇਗਾ। ਇੱਕ ਤੋਂ ਵੱਧ ਸਵਾਲ ਹੋਣ ਨਾਲ ਤਸਦੀਕ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਵਧਦਾ ਹੈ, ਅਤੇ ਇਹ ਬੇਤਰਤੀਬਤਾ (ਹਮੇਸ਼ਾਂ ਇੱਕੋ ਸਵਾਲ ਨਹੀਂ ਦਿਖਾਉਂਦੇ) ਨੂੰ ਜੋੜਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਅਸਲ ਉਪਭੋਗਤਾ ਪਾਸਵਰਡ ਭੁੱਲ ਜਾਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਰਿਡੰਡੈਂਸੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇੱਕ ਚੰਗਾ ਸੁਰੱਖਿਆ ਸਵਾਲ ਕੀ ਹੈ? ਇਹ ਕਈ ਕਾਰਕਾਂ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ:

1. ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਸੰਖੇਪ - ਸਵਾਲ ਸਪੱਸ਼ਟ ਅਤੇ ਅਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.
2. ਜਵਾਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਖਾਸ - ਸਾਨੂੰ ਅਜਿਹੇ ਸਵਾਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਜਿਸਦਾ ਜਵਾਬ ਇੱਕ ਵਿਅਕਤੀ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਦੇ ਸਕਦਾ ਹੈ
3. ਸੰਭਵ ਜਵਾਬ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਵਿਭਿੰਨ - ਕਿਸੇ ਦੇ ਮਨਪਸੰਦ ਰੰਗ ਨੂੰ ਪੁੱਛਣ ਨਾਲ ਸੰਭਵ ਜਵਾਬਾਂ ਦਾ ਇੱਕ ਬਹੁਤ ਛੋਟਾ ਉਪ ਸਮੂਹ ਮਿਲਦਾ ਹੈ
4. Поиск ਜਵਾਬ ਗੁੰਝਲਦਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਜੇਕਰ ਜਵਾਬ ਆਸਾਨੀ ਨਾਲ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕੋਈ ਵੀ (ਉੱਚੇ ਪਦਵੀਆਂ ਵਾਲੇ ਲੋਕਾਂ ਨੂੰ ਯਾਦ ਕਰੋ), ਤਾਂ ਉਹ ਬੁਰਾ ਹੈ
5. ਜਵਾਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਸਥਾਈ ਸਮੇਂ ਵਿੱਚ - ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਦੀ ਮਨਪਸੰਦ ਫਿਲਮ ਨੂੰ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਾਲ ਬਾਅਦ ਜਵਾਬ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ

ਜਿਵੇਂ ਕਿ ਇਹ ਵਾਪਰਦਾ ਹੈ, ਉੱਥੇ ਇੱਕ ਵੈਬਸਾਈਟ ਹੈ ਜੋ ਚੰਗੇ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਸਮਰਪਿਤ ਹੈ ਜਿਸ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ GoodSecurityQuestions.com. ਕੁਝ ਪ੍ਰਸ਼ਨ ਕਾਫ਼ੀ ਚੰਗੇ ਜਾਪਦੇ ਹਨ, ਦੂਸਰੇ ਉੱਪਰ ਦੱਸੇ ਗਏ ਕੁਝ ਟੈਸਟਾਂ ਨੂੰ ਪਾਸ ਨਹੀਂ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ "ਖੋਜ ਦੀ ਸੌਖ" ਟੈਸਟ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਉਪਭੋਗਤਾ ਨੂੰ ਹੇਠ ਲਿਖਿਆ ਪੱਤਰ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ:

ਹੁਣ ਤੱਕ ਸਭ ਕੁਝ ਆਮ ਹੈ, ਪਰ ਇੱਥੇ ਇਸ ਰੀਸੈਟ URL ਦੇ ਪਿੱਛੇ ਕੀ ਛੁਪਿਆ ਹੋਇਆ ਹੈ:

ਇਸ ਲਈ, ਸੁਰੱਖਿਆ ਸਵਾਲ ਖੇਡ ਵਿੱਚ ਆਉਂਦੇ ਹਨ. ਵਾਸਤਵ ਵਿੱਚ, PayPal ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਕੇ ਆਪਣਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨ ਦੀ ਵੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਸਲਈ ਇੱਕ ਵਾਧੂ ਚੈਨਲ ਹੈ ਜਿਸ ਤੱਕ ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੀ ਪਹੁੰਚ ਨਹੀਂ ਹੈ। ਮੈਂ ਜਵਾਬ ਦਿੱਤੇ ਬਿਨਾਂ ਆਪਣਾ ਪਾਸਵਰਡ ਨਹੀਂ ਬਦਲ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਦੋਵੇਂ ਸੁਰੱਖਿਆ ਸਵਾਲ (ਜਾਂ ਕਾਰਡ ਨੰਬਰ ਨਹੀਂ ਜਾਣਦਾ)। ਭਾਵੇਂ ਕਿਸੇ ਨੇ ਮੇਰੀ ਈਮੇਲ ਨੂੰ ਹਾਈਜੈਕ ਕੀਤਾ ਹੋਵੇ, ਉਹ ਮੇਰੇ PayPal ਖਾਤੇ ਦਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਗੇ ਜਦੋਂ ਤੱਕ ਉਹ ਮੇਰੇ ਬਾਰੇ ਥੋੜੀ ਹੋਰ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਜਾਣਦੇ। ਕੀ ਜਾਣਕਾਰੀ? ਇਹ ਸੁਰੱਖਿਆ ਪ੍ਰਸ਼ਨ ਵਿਕਲਪ ਹਨ ਜੋ PayPal ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ:

ਸਕੂਲ ਅਤੇ ਹਸਪਤਾਲ ਦਾ ਸਵਾਲ ਖੋਜ ਦੀ ਸੌਖ ਦੇ ਰੂਪ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਅਜੀਬ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਦੂਸਰੇ ਬਹੁਤ ਮਾੜੇ ਨਹੀਂ ਹਨ। ਹਾਲਾਂਕਿ, ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਣ ਲਈ, PayPal ਨੂੰ ਵਾਧੂ ਪਛਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਬਦੀਲੀ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ:

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

ਸੁਰੱਖਿਆ ਪ੍ਰਸ਼ਨ ਪ੍ਰਣਾਲੀ ਦੀ ਸਹੂਲਤ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਤੁਰੰਤ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹੋ ਜੇਕਰ ਸਰੋਤ ਸੁਰੱਖਿਆ ਦੇ ਪੱਧਰ ਦੀ ਲੋੜ ਹੈ। ਇਸਦਾ ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਣ ਐਪਲ ਹੈ, ਜਿਸ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਇਸ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ [2012 ਵਿੱਚ ਲਿਖਿਆ ਲੇਖ]. ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੈਂ ਆਪਣੇ ਆਈਪੈਡ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਤਾਂ ਮੈਂ ਹੇਠਾਂ ਦਿੱਤੀ ਬੇਨਤੀ ਦੇਖੀ:

ਫਿਰ ਮੈਂ ਇੱਕ ਸਕ੍ਰੀਨ ਵੇਖੀ ਜਿੱਥੇ ਮੈਂ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਅਤੇ ਜਵਾਬਾਂ ਦੇ ਕਈ ਜੋੜੇ ਚੁਣ ਸਕਦਾ ਹਾਂ, ਨਾਲ ਹੀ ਇੱਕ ਬਚਾਅ ਈਮੇਲ ਪਤਾ:

ਪੇਪਾਲ ਲਈ, ਪ੍ਰਸ਼ਨ ਪਹਿਲਾਂ ਤੋਂ ਚੁਣੇ ਗਏ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਅਸਲ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਹਨ:

ਤਿੰਨ ਸਵਾਲ/ਜਵਾਬ ਜੋੜੇ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਸੰਭਾਵਿਤ ਸਵਾਲਾਂ ਦੇ ਇੱਕ ਵੱਖਰੇ ਸਮੂਹ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਇਸਲਈ ਇੱਕ ਖਾਤੇ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ।

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

ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਅਤੇ ਜਵਾਬਾਂ ਦਾ ਇੱਕ ਅੰਤਮ ਪਹਿਲੂ ਇਹ ਹੈ ਕਿ ਉਹ ਸੋਸ਼ਲ ਇੰਜਨੀਅਰਿੰਗ ਲਈ ਵਧੇਰੇ ਕਮਜ਼ੋਰ ਹਨ। ਕਿਸੇ ਹੋਰ ਦੇ ਖਾਤੇ ਵਿੱਚ ਸਿੱਧੇ ਪਾਸਵਰਡ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਇੱਕ ਚੀਜ਼ ਹੈ, ਪਰ ਇਸਦੇ ਗਠਨ (ਇੱਕ ਪ੍ਰਸਿੱਧ ਸੁਰੱਖਿਆ ਸਵਾਲ) ਬਾਰੇ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰਨਾ ਬਿਲਕੁਲ ਵੱਖਰਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਤੁਸੀਂ ਕਿਸੇ ਵਿਅਕਤੀ ਨਾਲ ਉਹਨਾਂ ਦੇ ਜੀਵਨ ਦੇ ਬਹੁਤ ਸਾਰੇ ਪਹਿਲੂਆਂ ਬਾਰੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਸ਼ੱਕ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਗੁਪਤ ਸਵਾਲ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਬੇਸ਼ੱਕ, ਇੱਕ ਸੁਰੱਖਿਆ ਸਵਾਲ ਦਾ ਬਹੁਤ ਹੀ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਦੇ ਜੀਵਨ ਅਨੁਭਵ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਇਸ ਲਈ ਇਹ ਯਾਦਗਾਰ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਮੱਸਿਆ ਹੈ - ਲੋਕ ਆਪਣੇ ਜੀਵਨ ਦੇ ਤਜ਼ਰਬਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ! ਇਸ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਕੇਵਲ ਤਾਂ ਹੀ ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹੇ ਸੁਰੱਖਿਆ ਸਵਾਲ ਵਿਕਲਪ ਚੁਣਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਹਨ ਘੱਟ ਸ਼ਾਇਦ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਦੁਆਰਾ ਬਾਹਰ ਕੱਢਿਆ ਜਾ ਸਕਦਾ ਹੈ.

[ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ.]

ਇੱਕ ਇਸ਼ਤਿਹਾਰ ਦੇ ਤੌਰ ਤੇ

ਵੀਡੀਸੀਨਾ ਭਰੋਸੇਯੋਗ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ ਰੋਜ਼ਾਨਾ ਭੁਗਤਾਨ ਦੇ ਨਾਲ ਸਰਵਰ, ਹਰੇਕ ਸਰਵਰ 500 Megabits ਦੇ ਇੱਕ ਇੰਟਰਨੈਟ ਚੈਨਲ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਅਤੇ DDoS ਹਮਲਿਆਂ ਤੋਂ ਮੁਫਤ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੈ!

ਸਰੋਤ: www.habr.com