ਪਾਸਵਰਡ ਈਮੇਲ ਉਲਟਣਯੋਗਤਾ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਸਕੀਮਾ ਨਹੀਂ

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

ਸਬੂਤ ਨੂੰ ਉਸੇ ਪੱਧਰ ਉੱਤੇ ਰੱਖੋ, ਅਤੇ ਸਮੀਖਿਆ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਸਹੀ ਰਹੇਗਾ।

ਪੁਰਾਣਾ ਭੇਤ ਵਾਪਸ ਭੇਜਣਾ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

ਵਿਚਕਾਰਲੀ ਹਾਲਤ ਵੱਲ ਵੀ ਧਿਆਨ ਦਿਓ: ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ ਹੋਣ ਵਾਲੀ ਚਾਬੀ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਇਨਕ੍ਰਿਪਟਿਡ ਬਲੌਬ ਵਿਹਾਰ ਵਿੱਚ ਉਲਟਣਯੋਗ ਹੈ, ਭਾਵੇਂ ਰਿਪੋਰਟ ਵਿੱਚ ਇਨਕ੍ਰਿਪਟਿਡ ਸ਼ਬਦ ਭਰੋਸਾ ਦੇਣ ਵਾਲਾ ਲੱਗੇ।

ਇਹ ਡਿਜ਼ਾਈਨ ਖੋਜ ਕਿਉਂ ਹੈ, ਸਟੋਰੇਜ ਦਾ ਨਕਸ਼ਾ ਨਹੀਂ

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

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

ਰੀਸੈਟ ਨੂੰ ਅਧਿਕਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਓ

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

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

ਪਾਸਵਰਡ ਜਿਸ ਦੀ ਰਾਖੀ ਕਰਦਾ ਸੀ ਉਸ ਨੂੰ ਅਵੈਧ ਕਰੋ

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

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

ਸਹੀ ਮੁਲਾਂਕਣ ਛੋਟਾ ਹੈ: ਸੁਨੇਹਾ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਕੀ ਅਣਜਾਣ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤੀ ਨਿਯੰਤਰਿਤ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਪਹੁੰਚ ਦੀ ਥਾਂ ਲੈਂਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।