WEBVTT 00:00.760 --> 00:08.650 Broken authentication occurs when the application Miss managers session related information such that 00:08.740 --> 00:13.770 the user's identity will be compromised before deep diving. 00:13.780 --> 00:21.430 We need to talk about what is the session first and what is the session I.D. then how each TTP and session 00:21.460 --> 00:27.910 I.D. are or how does each TTP handle session I.D. first. 00:28.080 --> 00:36.150 If such an idea is unique to each user it is used for only one authenticated session. 00:36.310 --> 00:43.430 It is generated by the server and sent to the client in many forms such as hidden variable. 00:43.480 --> 00:53.530 It can be a cookie or a are L query string and the user is expected to send the same idea upon the next 00:53.620 --> 00:54.580 request. 00:54.580 --> 00:59.030 Now how does each TTP handle session I.D.. 00:59.110 --> 01:08.020 Unfortunately HDTV and HDTV s protocols they do not provide tracking of users session. 01:08.020 --> 01:17.110 So typically vendors will provide a built in session tracking methodology or developers will develop 01:17.110 --> 01:20.410 their own approach to handle sessions. 01:20.440 --> 01:29.260 Thus a room for error can occur attackers will take advantage of such bad session management practices 01:29.620 --> 01:35.140 to compromise password keys or authentication tokens. 01:35.140 --> 01:44.230 The aim here is to either get into someone else's session or use a session which has been ended by the 01:44.230 --> 01:48.730 user to steal session related information. 01:48.790 --> 01:50.910 The session is guest. 01:50.920 --> 01:57.820 This is especially useful if the session at hand is for a privileged account. 01:57.820 --> 02:06.340 Some examples on how to steal sessions are pressing the backward button after log out to see if you 02:06.340 --> 02:11.670 can stills view the previous page and access the session itself. 02:11.680 --> 02:17.620 You can try to head the euro out very key after logging out to check if you were able to access the 02:17.620 --> 02:22.360 page check for the presence of session related information in the URL. 02:22.360 --> 02:30.670 Because sometimes developers pass such information and get your real strings and you can as well try 02:30.940 --> 02:36.870 to find some credentials in the source code itself by right clicking on the page and view source. 02:36.880 --> 02:38.610 Sometimes coders. 02:38.620 --> 02:43.270 They just hard code credentials for ease of access. 02:43.270 --> 02:52.120 We can protect our self from broken authentication attacks using various ways such as using long and 02:52.120 --> 02:56.180 complex random session I.D. that cannot be guessed. 02:56.320 --> 03:04.090 It is always recommended to use each s to prevent disclosure of session I.D. using various men in the 03:04.090 --> 03:06.370 middle type of attacks. 03:06.370 --> 03:12.590 Always use secure Cookies make sure this session is timed out on the server. 03:12.620 --> 03:19.780 Consider regenerating a new session upon successful authentication or privilege level change. 03:20.060 --> 03:28.600 New URL query string should not be used for session I.D. because this is easily the Kosovo and always 03:28.600 --> 03:34.240 use or whenever possible use multi factor authentication.