You missed an extremely important point at 9:20 IMO. You said that it requires a vulnerability, e.g. SQL injection, for clear-text passwords to be a problem, but you forgot about employees! If someone who works for Twitter, who has legitimate admin access to the database, can see your plain-text password, then they can also use that password in order to hijack your identity at OTHER WEBSITES where they DO NOT work. This is a far easier argument to make, and completely circumvents needing a real vulnerability to exist that allows external users to access the data in Twitter's database, because now, even a *perfectly* secure application will still enable critical security vulnerabilities if passwords are stored in plain-text (according to the user's threat model, of course, since the service provider in this case is the bad actor).
Of course, you'd be trusting the bad actor to do the password hashing in this case, but at least that means that everyone who interacts with the database would have to ignore the obvious vulnerability of plaintext passwords, not just the one or few bad actors. The entire team would have to be complicit in any crime of ignorance or malice.
point is that this single owner rabbit simply could add request data logging and still steal the clear-text password. So we always have to trust the rabbit in this case and thus we have to exclude it from our threat model.
Chain of trust is the same whether we're the end user - trusting that Rabbit is not evil - and the Rabbit - trusting that his collaborators are not evil
I would agree that lack of backend session invalidation once pressing the logout button is a security "weakness". It unnecessarily increases the attack surface. It might be a theoretical issue, a low severity one, even if everything else is secured (no csrf), but security is like an onion. We have to make sure all layers of it are secure 🙃 it's our job maan, we have to report anything we find
It should also be noted that each device has its own session scope, that means logging out on one device doesn't log you out on another. But once you change your password, all sessions are invalidated, but the one you're changing password from.
@@CZghost "concurrent user logins" is an entirely different security weakness in this case. Depends on the application really (whether it's web, desktop, mobile etc.) and the way login information is stored
Overall I very much enjoyed this video. I was already familiar with problem of badly defined threat models that lead to bad definition of what makes something a vulnerability. But I have to say you did a very good job communicating the core points here for people that haven't learned this lesson from experience yet. It's a great resource to fast-track to a lot of insights that can take years to figure out on your own. I just want to mention that I am always a bit annoyed by provocative tweets like "cleartext passwords in a database..." because, yes, you are technically correct, and its an opportunity to engage people into an important discussion. But it really comes across as pedantic even though I can see that your larger point justifies the statement. Another thing to consider is that provocative tweets like that probably mostly engage people that actually know better already. And people that agree out of ignorance will probably not take part in the discussion and just end up with a confirmation of an problematic belief. A few might actually follow the conversations just to see how you justify something. But this is typically something you do if you disagree. If I agree with something I find myself much more likely to just go on without digging deeper into it. So it might do a lot of unintentional harm. Just something to keep in mind.
I like the idea of splitting the idea of a vulnerability and a weakness. We already have cve and cwe as industry standards that fit well around what you are saying. Cve is exploitable weakness in a system that may break a security boundary. Cwe are weaknesses that may lead to vulnerability occurring or may make a vulnerability worse than it could/should be
I've enjoyed this much more than the security related talks on my last container related conference. Even if it wasn't only it security related this is an important topic everywhere!
Another way to think about this is that companies which have BB or similar should have done their own "business needs for security" and threat modelling, both of which involves explicitly recognizing boundaries, assets, values, etc. These then should be made available to the public as part of the BB program. This is hard, because disclosing explicitly might make things worse because disclosing to the bad guys what the controls, etc. are. As for admin: we now know we can build systems so that there is a separation of duties here, at least to some degree - i.e., more boundaries are possible.
Love the background thingy, haven't seen your vids for a while and I as probably many other devs / it people appreciate the fact you haven't ironed the shirt yet :D Love from Poland and keep on the great work :D
@@LiveOverflow look, I'll be frank. I don't come here for the security stuff. I focus only on the appearances and on how neat dressed you are. Jokes aside I'm mentoring people from front-end point of view and use your vids as to why they should look at security in larger context. Maybe some of them watched this one so... "Hi!". :D
this kind of video really helps to orientate oneself to how a flaw is or is not a security risk, further to that though it just shows the complexity of the thought process needed to observe a vulnerability and then figure out how to attack it, absolutely wild imho
I would say it's a poor configuration/design choice, however that would indicate there is a gold standard or "best practice" and you know how we feel about best practices... 😉 Like you alluded to, it's all about the threat model. Just like ssh open on the internet, or password auth vs cert auth.
Oh, and the "theoretical" stuff - sometimes developers are told by business owners "don't spend more than X time on those security things" and so they want partial approaches. The HTTPOnly flag is one of them. I would never report such a matter in a BB, only in an internal pentest or scan report.
Takeaways: - definitions are weird. - If the attacker can already access the db it's game over - Use good password practices It's interesting seeing so many videos about semantics from your channel, but I suppose it's to be expected from any programmer. I'm not hating. Ya got some good ideas.
Very good video! You definitely changed the way how I think about XSS / CSRF mitigations. I have to admit I just accepted that using local storage is bad because of XSS vulns but in the end if u have XSS than not having the Session Token isnt really a problem as you said. And having to implement csrf tokenes and correct cookie flags can create more issues than just mitigating CSRF as a whole.
The problem with plain-text passwords is the same issue that happens with real locks that have the same keys or some "super"-keys for different reasons, regulations are most funny from them. We should redefine what password is and tell people that passwords should be unique from all other passwords you using in other places, idealy it should be just a random long-enough-to-boil-the-ocean string of text that easy to read, write and copy-paste (alpha-numeric ASCII should be enough).
Yeah, the word "password" is part of the problem. Normal people attach a specific concept to that word, and that concept is NOT a different, unique secret that they do not reuse. The historical origin of the word password implies reuse, because back when people only used it for secret societies and such, people usually only needed one password for one thing in their lives and there wasn't a good way for attackers to reuse passwords. Today's context is different. But because of historical path-dependency we still call this secret "password", leading the common user to think of it the same way. The first thought is to have one secret that they reuse everywhere to prove who they are. Many people would not even think of using multiple different passwords unless being told to do so by password strength checkers. And even less realize that their security depends on using unique secrets that are never reused. So instead of login pages having fields called "Username" and "Password", they could, for example, call it "Username" and "Secret Token". Or some other word that evokes the correct intuitions in most speakers of the language. But already I think the next step is to ditch the manual entry of username and passwords since using a proper password necessitates something like a password manager. So sites should directly interface with the password manager.
My Friend, you forgot to introduce defense in depth and single point of failure while explaining clear text password. Also, if user is able to view dashboard which has sensitive data using browser cache then it is vulnerability. Application must request browser not to cache such pages to avoid data leakage.
In my opinion, companies have a much too loose threat model in their IT in Germany in general. I mean, there are companies, that leave .csv files lying around on unused computers where all employees of a certain airline are listed with personal data, (employment status) etc. (cleartext of course!)
Hey man, would you mind making a playlist of the videos you have for a person who’s wanting to get into ethical hacking so we can learn all the basics and gradually move up to the more advanced stuff you have? It would be greatly appreciated
12:49 isn't hashing also exploitable? ie the hash for "cake" in SHA256 will always be the same, and if two or more websites end up storing that same hash, there really isn't a difference between cleartext in that situation. It leads to the tactic of logging tables of passwords and finding their respective hashes on demand (eg John the Ripper and hashcat). the best way to mitigate is is to salt the password before hashing (eg Website 1 adds 678hj before the password, and Website 2 add 0vseK before the password), making it way harder to find the correct hash.
but its depend on the hashing algorithm. if the algorithm is like private which can only be accessed by admin there is no way for hacker to put the password with sql injection because he has to know the algorithm. also using hashing makes it more secure for the hacker to log into the user account.
the example posted at @5:30 is an issue. Imagine you using a public computer, or someone elses, and you log into a website. Then, because you don't want them to be able to mess with your stuff, you log out. If they can bypass that by simply hitting the back button, that's a problem. Of course you trust that computer to be free of malicious software, say you use a family member's computer. But you still want your privacy. Whether that problem lies with the website or the browser caching it or whatever it is, it's a problem. @8:10 you're oversimplifying. In reality clear text passwords could be read by people who do not have authorization by the owner of the site, but still working there. If they change the server code to get the passwords from requests, that would be grounds for firing them and potential legal actions. Furthermore if a direct database access is given by some vulnerability, that compromises only that one website. The reality is that many users use the same passwords all over the place. It is irresponsible to risk disclosing passwords when it can be prevented simply by using some crypto library. The cleartext password is not in itself a vulnerability, but it's still a risk and might easily lead to one if any mistake is made along the way. Computer security and safety relies on layers of protection. @9:45 ...
I once had a similar argument with a coworker because I said I'd stored a credential in.a property file on my laptop. Yes it's not secure, but if someone has gained access to said laptop, there are far worse things they can do!
I have a interesting question for you please answer : what if i take a virus code or payload for reverse shell i know it can be defected my Antivirus but what if i creat 2 programs first take a second file input and replace a set of character with in a code " Like switching a letters inside code to another letters in a way not a single bit size increased or decreased of virus payload but code don't work " Then upload both file on target and excute first...so first file not be red flaged by Antivirus because nothing offensive in switching code program and second code don't work 😅so both install in system and after a while first file just run and make payload active ( correct all letters)
Consider that many kinds of malware encrypt their payloads specifically for this reason. That's the reason that signature-based virus detection is so weak. Modern detection is more about preventing ANYTHING from running without permission.
7:23 Eww, people still send passwords as plain text (over an encrypted link) instead of sending the user the salt and getting the browser to hash it before sending it? Like yeah the user shouldn't be reusing passwords or password styles, but people do! So just reduce the risk and pre-hash before sending.
Are you kidding? That's even more stupid! That means that an attacker who leaks the hashed passwords can log in with them directly! Plaintext password submissions within an encrypted channel are the best thing we have. The only way to defeat that is with MITM, and that gets mitigated with certificate validation.
Every time the word "capability" is used here, it should have been "authority". In security research, these terms have similar meanings, but are different in important ways. Authority describes what you are /able/ to do. For example, an unprivelaged user has the authority to update /etc/passwd using the passwd setuid binary, even though they do not have the permission to write to it. A capability is an unforgeable right to use authority, in the way that a process that has an open file can use its descriptor to express its authority to perform operations on the file. These meanings are not new, capability theory goes back to the pdp-1 and other systems from the 50s and 60s, though it appears to have fallen out of the zeitgeist since the endless september.
mh I don't quite understand the difference tbh. I'm thinking like the capabilities in Linux (which I believe are derived from capability theory). Imagine the webapp has CAP_DB_WRITE. Then the SQL injection vulnerability gives an attacker indirectly CAP_DB_WRITE as well?
@@LiveOverflow posix capabilities are not capabilities but ACLs; the name was either (depending on who you ask) slightly tongue-in-cheek, or a misinterpretation of one of the most well known properties of capabilities, that they are "fine grained" permission control. There's a paper that describes the difference in terms of the vulnerabilities that can be expressed with them called "ACLs Don't", by Tyler Close, that you might like.
I do not agree about redefining security weakness & vulnerability and the video or comments are a bit concerning as I see this as a big troll. A SQL injection which is a vulnerability for you should be a weakness: if your website is behind the ultimate WAF or if your visitors cannot exploit it. The clear text password is not a vulnerability for you because the admin can get your clear password anyways: this argument just forgets a lot of other risk scenarios... To sump up, both clear text and encrypted passwords in a database are a vulnerability, one is weaker than the other or not, depending on the risk scenario (source, leakage method).
You are so close!!! :D You are right, a SQL injection that cannot be exploit is not a vulnerability (because then it's not a SQL injection anymore lol). Another name for an "ultimate WAF" could be "perfect input validation", and then indeed, we don't have a vulnerability either ;) and lastly, how am I redefining these terms, when there already is not a definition we all can agree about. I showed in the video that different entities interpret it differently. So let me ask you, which one is the right one. Which one should we use?
Close? ^_^ I agree with you the label of these things is relative, to the dangerosity / exploitability and the amount of risk you take / consider. The unencrypted stored password for example is a weakness considered too _dangerous_ (in multiple scenarios), therefore we call it a vulnerability. The problem I see with this kind of reasoning, is not considering vulnerabilities enough which leads to no correction or dirty fixes (for example the WAF in case of injections, as it is not a 100% guarantee to prevent the injections working).
And about HttpOnly being useless, well yes cookies are unsecure by nature. The secure flag (not useless) or HTTPOnly (pretty useless) for cookies, encrypted passwords or not (in md5, sha512, salted, etc.), for both cases there are stronger mechanisms as these are vulnerable, or weak if you prefer :) If you can make a big change to replace an old mechanism like the use of passwords for example with security keys that's great, but in general "savings" are made.
I never comment on RUclips videos. But I think this is your best video. almost every topic of debate I've ever had on web security touched. I feel personally vindicated, thank you.
Of course it's a security vulnerability. There's too many things that can go wrong with cleartext passwords, especially given the fact that users often have the same password on many sites. I don't want to get into linguistic debate, a vulnerability and weakness is the same thing, let's not invent new terms just so we can be contrarian
it's not about being contrarian. It's about terms to differentiate between that provably breaks a security boundary directly. Versus that does not really break a security boundary and might or might not be mitigateable.
@@LiveOverflow I understood the video; I just don't think that one should be called security vulnerability while the other - not a security vulnerability
I really like this video and its approach to security. The concepts are something I'm constantly trying to explain to people and your scoping explanation does a great job. I also think your password explanation is pretty solid. Leaking to other sites is definitely the largest exploit. But I wonder if that's _because_ passwords are hashed, the only person that would exploit it is someone that could attack weak hashes or weak passwords. The context of that attack would be to harvest is for the value of coordinating it across sites. If passwords where never hashed, it would probably incentivize a different type of hack because getting that cleartext password would be immediately useful for escalating and getting more valuable assets. Also with my developer hat on, there is never one boundary. I trust my admin's with access to server logs and traffic more then the user generating reports of the database. And with one typo the later could get access to plaintext passwords which can then leak and be exploited. That's a also a pretty critical weakness that reasonably could be called a Vulnerability imho. Regardless. Awesome video! I expect I'll be referencing it in both my security and developer roles for a long time to come. Thanks!
@@svizelpritula4951I think you all missing one key point here. ofc clear passwords require other vulnerability first, but what if there was one? you don't want to keep it, you want to resolve it, right? so after you patched it, what next? attacker already stolen all user credentials, and is now able to login as any user without original issue existing any more in that case this also affects the original website (yes, I know leaking hashed passwords is also bad and you still want users to rotate them, but if it's secure enough password and hashing algorithm you might not need to lock every user account before password is changed, also you have second salt that is stored somewhere in server configuration instead of database, you might have high confidence that hashes will be useless to a attacker)
@@svizelpritula4951 if you read the post you're replying to, he's saying it's also a weakness/vulnerability within the server/website because there are layers of security even within the server's maintenance infrastructure / within the website's own security boundary. Basically the drawing of attack vectors in this video, all being external to the server security boundary, isn't fully accurate because within that box there are a bunch more computers and users which have their own security boundary structure... and keeping hashed passwords is part of creating an extra boundary between most of their users/employees and the user passwords, which in turn prevents those people from all having access to (for example) tweet as any user, despite being on the 'inside' of that security boundary where supposedly they could do that. Just struck me as very odd you repeated the video's overly simplified message (which he says in the video is just to accentuate where the fundamental security boundaries are) as a reply to someone literslly pointing out a situation where that claim isn't true.
I think "primary security vulnerability" is the best term for your "security vulnerability" term. And "secondary security vulnerabilty" is the best term for your "security weakness". Since its litterally a difference of needing one before the other. Which the words primary and secondary make ALOT clearer. Also that defining your own words thing is known in linguistics as your ideolect. Its the langage unique to a person. And everyone has one.
for the cleartext password case there is a defence in depth, where even if isolation of the sql read access break somehow (say a backup became public) those hashes (provided passwords are strong etc) will not be useful enough to compromise the user account. This relies on the even that only read access to a database would give write access (a privilege escalation) to content database.
That's a debate we (DBAs) had with the SecOps folks on the company, since we wanted to encrypt passwords in a specific db, the real threat is the surface level, in your example applied to the company I work for, the clear passwords are a risk, not a vulnerability, since the attacker may need to have access to the software that uses those credentials (that are unique to this software, as the software generates those logins and passwords itself), that is in another network, know how to operate said software (that is convoluted and the UX is atrocious), and how exactly to use that to do damage (no extense damage will be done and zero sensitive data will be accessed). So the real threath is the leak of a backup, and if that is taken care of, the clear text passwords are a non issue
This argument seems a bit simplified as it depicts a company as a single entity instead of an organization with a complex rights and access architecture. Therefore it makes senses to classify some issues (such as clear text pws) as vulnerabilities if the threat model does not only include external attackers but also other employees with i.e. read-only access to certain databases. In the end, you have to trust the admin, sure, but you don't have to trust everyone who works there and might gain sufficient rights to access sensitive data. Your point that the classification and severity of a security issue depends on the thread model and perspective is still valid and can also be applied here of course.
Your teaching style is fantastic! I admire how you start from the basics, guiding us from ground zero, exploring problems, and jointly inventing solutions. It's an incredibly engaging way to learn.
I disagree with the point made at 8:35 , it is quite possible to have an sql injection in a place where data modification is not possible (because of transactions or other issues). Data exfiltration for SQL injection is a much more reasonable scenario. Then having the password it would be trivial to login as Alice and do whatever is required without much notice.
17:40 the security boundary is between users of a shared machine. A user needs to be able to read and write their data, and they need to be able to ensure that a subsequent user cannot do the same. As I see it, creating this boundary is the express purpose of a "log out" button, so I take the existence of such a button as evidence that this security boundary is part of the threat model of some of the website's target users. The quoted tweet is describing a situation where a subsequent user can read some portion of the previous user's data, thus violating that security boundary.
This assumes other users sharing the same machine are not malicious, in which case they wouldn't violate the security boundary you described in the first place. If they are malicious, one of them could just install a keylogger or malware on that shared machine.
@@ThomasOrlita Your argument requires that the machine account being shared is capable of installing software. This is usually not true for shared machine accounts. Consider a library computer. The library almost certainly does not allow the account for guests to install software.
I would argue that clicking the back button even after logging out is a security vulnerability. Because even though the user deliberately tried to logout here, the session isn't destroyed and the cookie exists. What happens when in a later point of time a session hijacking malware captures this session gaining access to the user's account? Isn't the reason for this vulnerability the website itself and not the user?
What really bakes my noodle is when self-signed certificates end up getting left as the default certificate (usually because the IT engineers are lazy and don't bother to change it to a real certificate). Sometimes at my job I see a new service handed over to users who subsequently become trained by habit to click the "proceed anyway" button in the browser. Every time this happens a part of me wants to scream into a sweater. This makes for such an easy attack surface for an attacker who sets up a MITM attack to grab some data of value, just because they know the user is just likely to click through the warning message because they've sene that many times before...
Love the way you explain tricky security topics, When you posted that tweet, I was already on your side, I already knew 'storing passwords in clear text' is not a security issue. But I still watched your video and to be honest, the video was fun to watch.
Sometimes I catch myself imagining what it would be like from scratch, taking old paradigms and doing something new. new system and website/sustém & structure models have been created over the last 50 years, With what we learned from them and creating a new network....but even before writing this paragraph I see how stupid it is. 😂😅😢
Other than the great content itself, I just want to say the visuals in this video are lovely! Did you outsource the visual production for this episode?
Would clear text passwords be considered a vulnerability if someone used social engineering to get an admin or someone who has access to the database to read out the password or wouldn’t social engineering be the vulnerability?
his point is that fundamentally you can only 'trust or not trust' the server in your own threat model, so it makes no difference to you what their internal security is. If they are able to keep plaintext paswords securely, what do you care? Unless you reuse passwords, in which case now their internal security can impact yours. It's not intended to be literal, keeping plaintext passwords on a server is still just negligently introducing a 'weakness'.
How would you define security escalation in this context? Let's say in your initial example, the attacker found a vulnerability that grants access to the passwords. This could be a full read access to the entire database, including private information, but it could also be a simple log file that logs passwords, or maybe an internal service that only as read permissions on the database. In this example, the method of storing passwords does make a difference, even without adding another website, because now the attacker can escalate the read access into a full write access on the user level. Or maybe they infiltrated the company, and now leak the passwords, just to cause trouble for the company, without technically breaking any of the defined security boundaries. These are some of the reasons I would argue to treat this as a vulnerability, as it lets you hop over a security boundary after you managed to get over the first one (in this case read access, or the employment process, or from your example read and write access for other websites). I would think of a "weakness" more along these lines: You got access to the password database, got all the passwords. Now the company patches the original vulnerability, but you still have all the passwords and thus still have unauthorized access, the company has no way of patching directly. This is what I would consider a weakness, and not a vulnerability, because it does not grant any additional access, rather is bad after obtaining access, without hopping over more boundaries after the fact. I don't think I really got the point you are trying to make, or if it's similar to mine, I disagree with the argument and example.
you are absolutely right! In reality we define security boundaries within security boundaries. And your example of turning read access (leak pw) into write access (login with pw), is then also breaking a boundary. But I also wanted to make the point that we can define these security boundaries arbitrarily. And that "vulnerability" and "weakness" always have to be looked at with respect to the defined threat model and security boundaries. But your example is indeed generally a reasonable boundary to have in most cases.
This video shows how deep the rabbit hole goes. You can't just stay in wonderland here.
That bell notification came just in time when I looked at the phone. Finally a good reason to procrastinate writing my master thesis
WAYOO same boat. have fun writing in 30 min
@@artwes Thanks, you too :)
Good luck to you guys
You missed an extremely important point at 9:20 IMO. You said that it requires a vulnerability, e.g. SQL injection, for clear-text passwords to be a problem, but you forgot about employees! If someone who works for Twitter, who has legitimate admin access to the database, can see your plain-text password, then they can also use that password in order to hijack your identity at OTHER WEBSITES where they DO NOT work. This is a far easier argument to make, and completely circumvents needing a real vulnerability to exist that allows external users to access the data in Twitter's database, because now, even a *perfectly* secure application will still enable critical security vulnerabilities if passwords are stored in plain-text (according to the user's threat model, of course, since the service provider in this case is the bad actor).
Of course, you'd be trusting the bad actor to do the password hashing in this case, but at least that means that everyone who interacts with the database would have to ignore the obvious vulnerability of plaintext passwords, not just the one or few bad actors. The entire team would have to be complicit in any crime of ignorance or malice.
This is the point of having a defined threat model though - has nothing to do with MAKING the server vulnerable.
point is that this single owner rabbit simply could add request data logging and still steal the clear-text password. So we always have to trust the rabbit in this case and thus we have to exclude it from our threat model.
@@LiveOverflowYeah but the attack surface is bigger because maybe the DB admin only has access to the DB server, but not to the app itself.
Chain of trust is the same whether we're the end user - trusting that Rabbit is not evil - and the Rabbit - trusting that his collaborators are not evil
I just finished a major yearly review of my company's products. What you said here is exactly what I needed to communicate to several people.
Go get them
when you present it I hope you use the accent too.
I would agree that lack of backend session invalidation once pressing the logout button is a security "weakness". It unnecessarily increases the attack surface. It might be a theoretical issue, a low severity one, even if everything else is secured (no csrf), but security is like an onion. We have to make sure all layers of it are secure 🙃 it's our job maan, we have to report anything we find
It should also be noted that each device has its own session scope, that means logging out on one device doesn't log you out on another. But once you change your password, all sessions are invalidated, but the one you're changing password from.
@@CZghost "concurrent user logins" is an entirely different security weakness in this case. Depends on the application really (whether it's web, desktop, mobile etc.) and the way login information is stored
Overall I very much enjoyed this video. I was already familiar with problem of badly defined threat models that lead to bad definition of what makes something a vulnerability. But I have to say you did a very good job communicating the core points here for people that haven't learned this lesson from experience yet. It's a great resource to fast-track to a lot of insights that can take years to figure out on your own. I just want to mention that I am always a bit annoyed by provocative tweets like "cleartext passwords in a database..." because, yes, you are technically correct, and its an opportunity to engage people into an important discussion. But it really comes across as pedantic even though I can see that your larger point justifies the statement.
Another thing to consider is that provocative tweets like that probably mostly engage people that actually know better already. And people that agree out of ignorance will probably not take part in the discussion and just end up with a confirmation of an problematic belief. A few might actually follow the conversations just to see how you justify something. But this is typically something you do if you disagree. If I agree with something I find myself much more likely to just go on without digging deeper into it. So it might do a lot of unintentional harm.
Just something to keep in mind.
I like the idea of splitting the idea of a vulnerability and a weakness. We already have cve and cwe as industry standards that fit well around what you are saying.
Cve is exploitable weakness in a system that may break a security boundary. Cwe are weaknesses that may lead to vulnerability occurring or may make a vulnerability worse than it could/should be
I've enjoyed this much more than the security related talks on my last container related conference. Even if it wasn't only it security related this is an important topic everywhere!
Another way to think about this is that companies which have BB or similar should have done their own "business needs for security" and threat modelling, both of which involves explicitly recognizing boundaries, assets, values, etc. These then should be made available to the public as part of the BB program. This is hard, because disclosing explicitly might make things worse because disclosing to the bad guys what the controls, etc. are. As for admin: we now know we can build systems so that there is a separation of duties here, at least to some degree - i.e., more boundaries are possible.
Love the background thingy, haven't seen your vids for a while and I as probably many other devs / it people appreciate the fact you haven't ironed the shirt yet :D
Love from Poland and keep on the great work :D
my SO asked me earlier "how many comments do you think will you get about your shirt this video?"
@@LiveOverflow look, I'll be frank. I don't come here for the security stuff. I focus only on the appearances and on how neat dressed you are.
Jokes aside I'm mentoring people from front-end point of view and use your vids as to why they should look at security in larger context. Maybe some of them watched this one so... "Hi!". :D
this kind of video really helps to orientate oneself to how a flaw is or is not a security risk, further to that though it just shows the complexity of the thought process needed to observe a vulnerability and then figure out how to attack it, absolutely wild imho
Do you have a better name for what I call vulnerability vs. weakness?
not really
aware vs unaware threats
I would say it's a poor configuration/design choice, however that would indicate there is a gold standard or "best practice" and you know how we feel about best practices... 😉
Like you alluded to, it's all about the threat model. Just like ssh open on the internet, or password auth vs cert auth.
Concern vs. Hassle
Vulnerability vs. Missing Security Control
Oh, and the "theoretical" stuff - sometimes developers are told by business owners "don't spend more than X time on those security things" and so they want partial approaches. The HTTPOnly flag is one of them. I would never report such a matter in a BB, only in an internal pentest or scan report.
Takeaways:
- definitions are weird.
- If the attacker can already access the db it's game over
- Use good password practices
It's interesting seeing so many videos about semantics from your channel, but I suppose it's to be expected from any programmer.
I'm not hating. Ya got some good ideas.
16:23 I'm dying laughing. Your sense of humor is awesome!
Very good video! You definitely changed the way how I think about XSS / CSRF mitigations. I have to admit I just accepted that using local storage is bad because of XSS vulns but in the end if u have XSS than not having the Session Token isnt really a problem as you said. And having to implement csrf tokenes and correct cookie flags can create more issues than just mitigating CSRF as a whole.
The problem with plain-text passwords is the same issue that happens with real locks that have the same keys or some "super"-keys for different reasons, regulations are most funny from them. We should redefine what password is and tell people that passwords should be unique from all other passwords you using in other places, idealy it should be just a random long-enough-to-boil-the-ocean string of text that easy to read, write and copy-paste (alpha-numeric ASCII should be enough).
Yeah, the word "password" is part of the problem. Normal people attach a specific concept to that word, and that concept is NOT a different, unique secret that they do not reuse.
The historical origin of the word password implies reuse, because back when people only used it for secret societies and such, people usually only needed one password for one thing in their lives and there wasn't a good way for attackers to reuse passwords.
Today's context is different. But because of historical path-dependency we still call this secret "password", leading the common user to think of it the same way. The first thought is to have one secret that they reuse everywhere to prove who they are. Many people would not even think of using multiple different passwords unless being told to do so by password strength checkers. And even less realize that their security depends on using unique secrets that are never reused.
So instead of login pages having fields called "Username" and "Password", they could, for example, call it "Username" and "Secret Token". Or some other word that evokes the correct intuitions in most speakers of the language. But already I think the next step is to ditch the manual entry of username and passwords since using a proper password necessitates something like a password manager. So sites should directly interface with the password manager.
My Friend, you forgot to introduce defense in depth and single point of failure while explaining clear text password. Also, if user is able to view dashboard which has sensitive data using browser cache then it is vulnerability. Application must request browser not to cache such pages to avoid data leakage.
14:00
why is there an extra } in the fetch example?
In my opinion, companies have a much too loose threat model in their IT in Germany in general. I mean, there are companies, that leave .csv files lying around on unused computers where all employees of a certain airline are listed with personal data, (employment status) etc. (cleartext of course!)
Hey man, would you mind making a playlist of the videos you have for a person who’s wanting to get into ethical hacking so we can learn all the basics and gradually move up to the more advanced stuff you have? It would be greatly appreciated
12:49 isn't hashing also exploitable? ie the hash for "cake" in SHA256 will always be the same, and if two or more websites end up storing that same hash, there really isn't a difference between cleartext in that situation. It leads to the tactic of logging tables of passwords and finding their respective hashes on demand (eg John the Ripper and hashcat). the best way to mitigate is is to salt the password before hashing (eg Website 1 adds 678hj before the password, and Website 2 add 0vseK before the password), making it way harder to find the correct hash.
but its depend on the hashing algorithm. if the algorithm is like private which can only be accessed by admin there is no way for hacker to put the password with sql injection because he has to know the algorithm. also using hashing makes it more secure for the hacker to log into the user account.
the example posted at @5:30 is an issue. Imagine you using a public computer, or someone elses, and you log into a website. Then, because you don't want them to be able to mess with your stuff, you log out.
If they can bypass that by simply hitting the back button, that's a problem.
Of course you trust that computer to be free of malicious software, say you use a family member's computer. But you still want your privacy.
Whether that problem lies with the website or the browser caching it or whatever it is, it's a problem.
@8:10 you're oversimplifying. In reality clear text passwords could be read by people who do not have authorization by the owner of the site, but still working there. If they change the server code to get the passwords from requests, that would be grounds for firing them and potential legal actions. Furthermore if a direct database access is given by some vulnerability, that compromises only that one website. The reality is that many users use the same passwords all over the place. It is irresponsible to risk disclosing passwords when it can be prevented simply by using some crypto library. The cleartext password is not in itself a vulnerability, but it's still a risk and might easily lead to one if any mistake is made along the way. Computer security and safety relies on layers of protection.
@9:45 ...
I once had a similar argument with a coworker because I said I'd stored a credential in.a property file on my laptop.
Yes it's not secure, but if someone has gained access to said laptop, there are far worse things they can do!
I have a interesting question for you please answer : what if i take a virus code or payload for reverse shell i know it can be defected my Antivirus but what if i creat 2 programs first take a second file input and replace a set of character with in a code " Like switching a letters inside code to another letters in a way not a single bit size increased or decreased of virus payload but code don't work " Then upload both file on target and excute first...so first file not be red flaged by Antivirus because nothing offensive in switching code program and second code don't work 😅so both install in system and after a while first file just run and make payload active ( correct all letters)
Consider that many kinds of malware encrypt their payloads specifically for this reason. That's the reason that signature-based virus detection is so weak. Modern detection is more about preventing ANYTHING from running without permission.
I have my Computer Networks test tomorrow but instead of my textbook I am looking at this 😂
Wonder how much I'll score.....
my bad security takes probably get you into trouble! better study the textbook
CyberSecurity Specialists nowadays don't even know which one is vulnerability and which one is security weakness.
7:23 Eww, people still send passwords as plain text (over an encrypted link) instead of sending the user the salt and getting the browser to hash it before sending it? Like yeah the user shouldn't be reusing passwords or password styles, but people do! So just reduce the risk and pre-hash before sending.
Are you kidding? That's even more stupid! That means that an attacker who leaks the hashed passwords can log in with them directly!
Plaintext password submissions within an encrypted channel are the best thing we have. The only way to defeat that is with MITM, and that gets mitigated with certificate validation.
..3 machines,, machine C for the data.. machine B for middle-man if requirementsare fullfilled between machine A and who requires the data..
nice graphics this time
We called those missing security controls here
Push!
Every time the word "capability" is used here, it should have been "authority". In security research, these terms have similar meanings, but are different in important ways.
Authority describes what you are /able/ to do. For example, an unprivelaged user has the authority to update /etc/passwd using the passwd setuid binary, even though they do not have the permission to write to it. A capability is an unforgeable right to use authority, in the way that a process that has an open file can use its descriptor to express its authority to perform operations on the file.
These meanings are not new, capability theory goes back to the pdp-1 and other systems from the 50s and 60s, though it appears to have fallen out of the zeitgeist since the endless september.
mh I don't quite understand the difference tbh.
I'm thinking like the capabilities in Linux (which I believe are derived from capability theory). Imagine the webapp has CAP_DB_WRITE. Then the SQL injection vulnerability gives an attacker indirectly CAP_DB_WRITE as well?
@@LiveOverflow posix capabilities are not capabilities but ACLs; the name was either (depending on who you ask) slightly tongue-in-cheek, or a misinterpretation of one of the most well known properties of capabilities, that they are "fine grained" permission control. There's a paper that describes the difference in terms of the vulnerabilities that can be expressed with them called "ACLs Don't", by Tyler Close, that you might like.
or - I have a youtube playlist linked from my user page if you want to dig deeper.
you're amazing
I do not agree about redefining security weakness & vulnerability and the video or comments are a bit concerning as I see this as a big troll.
A SQL injection which is a vulnerability for you should be a weakness: if your website is behind the ultimate WAF or if your visitors cannot exploit it.
The clear text password is not a vulnerability for you because the admin can get your clear password anyways: this argument just forgets a lot of other risk scenarios...
To sump up, both clear text and encrypted passwords in a database are a vulnerability, one is weaker than the other or not, depending on the risk scenario (source, leakage method).
You are so close!!! :D
You are right, a SQL injection that cannot be exploit is not a vulnerability (because then it's not a SQL injection anymore lol).
Another name for an "ultimate WAF" could be "perfect input validation", and then indeed, we don't have a vulnerability either ;)
and lastly, how am I redefining these terms, when there already is not a definition we all can agree about. I showed in the video that different entities interpret it differently. So let me ask you, which one is the right one. Which one should we use?
Close? ^_^ I agree with you the label of these things is relative, to the dangerosity / exploitability and the amount of risk you take / consider. The unencrypted stored password for example is a weakness considered too _dangerous_ (in multiple scenarios), therefore we call it a vulnerability.
The problem I see with this kind of reasoning, is not considering vulnerabilities enough which leads to no correction or dirty fixes (for example the WAF in case of injections, as it is not a 100% guarantee to prevent the injections working).
And about HttpOnly being useless, well yes cookies are unsecure by nature. The secure flag (not useless) or HTTPOnly (pretty useless) for cookies, encrypted passwords or not (in md5, sha512, salted, etc.), for both cases there are stronger mechanisms as these are vulnerable, or weak if you prefer :)
If you can make a big change to replace an old mechanism like the use of passwords for example with security keys that's great, but in general "savings" are made.
29 seconds ago 👀
@liveoverflow Is hextree signup supposed to be a challenge or is it really disabled at the moment?
still closed beta. sign up for the waiting list pls :)
Just save your password in a text file.
Extreme security.
👍
Ok buddy
If only people stopped reusing passwords and using unique strong passwords or passphrases.
Hello ❤
Alice In Wonderland.
I never comment on RUclips videos. But I think this is your best video. almost every topic of debate I've ever had on web security touched.
I feel personally vindicated, thank you.
😂❤
18:26 well I guess you havent worked on National level security haha
only compliance/ISO audits cares about security weaknesses
Not sure if thumbnail is an undercover furry outing
I would very much prefer if the video didn't contain AI art
I prefer it with AI art. I guess we just have a different threat model :P
Of course it's a security vulnerability. There's too many things that can go wrong with cleartext passwords, especially given the fact that users often have the same password on many sites. I don't want to get into linguistic debate, a vulnerability and weakness is the same thing, let's not invent new terms just so we can be contrarian
it's not about being contrarian. It's about terms to differentiate between that provably breaks a security boundary directly. Versus that does not really break a security boundary and might or might not be mitigateable.
@@LiveOverflow I understood the video; I just don't think that one should be called security vulnerability while the other - not a security vulnerability
how would you differentiate the two then? So you can focus on the stuff that matters, and ignore the stuff that doesn't?
I really like this video and its approach to security. The concepts are something I'm constantly trying to explain to people and your scoping explanation does a great job.
I also think your password explanation is pretty solid. Leaking to other sites is definitely the largest exploit. But I wonder if that's _because_ passwords are hashed, the only person that would exploit it is someone that could attack weak hashes or weak passwords. The context of that attack would be to harvest is for the value of coordinating it across sites. If passwords where never hashed, it would probably incentivize a different type of hack because getting that cleartext password would be immediately useful for escalating and getting more valuable assets.
Also with my developer hat on, there is never one boundary. I trust my admin's with access to server logs and traffic more then the user generating reports of the database. And with one typo the later could get access to plaintext passwords which can then leak and be exploited. That's a also a pretty critical weakness that reasonably could be called a Vulnerability imho.
Regardless. Awesome video! I expect I'll be referencing it in both my security and developer roles for a long time to come. Thanks!
absolutely right, in reality we have security boundaries within security boundaries within security boundaries ....
In a way, plaintext passwords are a vulnerability for every website other than the one that uses them.
@@svizelpritula4951I think you all missing one key point here.
ofc clear passwords require other vulnerability first, but what if there was one?
you don't want to keep it, you want to resolve it, right?
so after you patched it, what next? attacker already stolen all user credentials, and is now able to login as any user without original issue existing any more
in that case this also affects the original website
(yes, I know leaking hashed passwords is also bad and you still want users to rotate them, but if it's secure enough password and hashing algorithm you might not need to lock every user account before password is changed, also you have second salt that is stored somewhere in server configuration instead of database, you might have high confidence that hashes will be useless to a attacker)
@@svizelpritula4951 if you read the post you're replying to, he's saying it's also a weakness/vulnerability within the server/website because there are layers of security even within the server's maintenance infrastructure / within the website's own security boundary.
Basically the drawing of attack vectors in this video, all being external to the server security boundary, isn't fully accurate because within that box there are a bunch more computers and users which have their own security boundary structure... and keeping hashed passwords is part of creating an extra boundary between most of their users/employees and the user passwords, which in turn prevents those people from all having access to (for example) tweet as any user, despite being on the 'inside' of that security boundary where supposedly they could do that.
Just struck me as very odd you repeated the video's overly simplified message (which he says in the video is just to accentuate where the fundamental security boundaries are) as a reply to someone literslly pointing out a situation where that claim isn't true.
😂❤
I think "primary security vulnerability" is the best term for your "security vulnerability" term.
And "secondary security vulnerabilty" is the best term for your "security weakness".
Since its litterally a difference of needing one before the other. Which the words primary and secondary make ALOT clearer.
Also that defining your own words thing is known in linguistics as your ideolect. Its the langage unique to a person. And everyone has one.
for the cleartext password case there is a defence in depth, where even if isolation of the sql read access break somehow (say a backup became public) those hashes (provided passwords are strong etc) will not be useful enough to compromise the user account. This relies on the even that only read access to a database would give write access (a privilege escalation) to content database.
Yeah this is like saying an LPE isn't a vulnerability because you would have to access the server first
That's a debate we (DBAs) had with the SecOps folks on the company, since we wanted to encrypt passwords in a specific db, the real threat is the surface level, in your example applied to the company I work for, the clear passwords are a risk, not a vulnerability, since the attacker may need to have access to the software that uses those credentials (that are unique to this software, as the software generates those logins and passwords itself), that is in another network, know how to operate said software (that is convoluted and the UX is atrocious), and how exactly to use that to do damage (no extense damage will be done and zero sensitive data will be accessed). So the real threath is the leak of a backup, and if that is taken care of, the clear text passwords are a non issue
5 mins in and mans is already dropping fantastic points. such a great infosec channel
Simple, don't use sql and there won't be no sql injection 😜
You made one mistake though....going on twitter to state your opinion, lmao
You could have stopped at "going on twitter"
This argument seems a bit simplified as it depicts a company as a single entity instead of an organization with a complex rights and access architecture. Therefore it makes senses to classify some issues (such as clear text pws) as vulnerabilities if the threat model does not only include external attackers but also other employees with i.e. read-only access to certain databases. In the end, you have to trust the admin, sure, but you don't have to trust everyone who works there and might gain sufficient rights to access sensitive data.
Your point that the classification and severity of a security issue depends on the thread model and perspective is still valid and can also be applied here of course.
yeah in reality we have security boundaries within security boundaries. The deeper we go, the less severe the issues get.
Your teaching style is fantastic! I admire how you start from the basics, guiding us from ground zero, exploring problems, and jointly inventing solutions. It's an incredibly engaging way to learn.
yes, proving his point from first principles. I love his style!
I disagree with the point made at 8:35 , it is quite possible to have an sql injection in a place where data modification is not possible (because of transactions or other issues). Data exfiltration for SQL injection is a much more reasonable scenario. Then having the password it would be trivial to login as Alice and do whatever is required without much notice.
hey can you please do a video on binarly's logofail uefi vulnerability
Hashing passwords on client-side, sending it to the server already hashed should have been mentioned.
17:40 the security boundary is between users of a shared machine. A user needs to be able to read and write their data, and they need to be able to ensure that a subsequent user cannot do the same. As I see it, creating this boundary is the express purpose of a "log out" button, so I take the existence of such a button as evidence that this security boundary is part of the threat model of some of the website's target users. The quoted tweet is describing a situation where a subsequent user can read some portion of the previous user's data, thus violating that security boundary.
This assumes other users sharing the same machine are not malicious, in which case they wouldn't violate the security boundary you described in the first place.
If they are malicious, one of them could just install a keylogger or malware on that shared machine.
@@ThomasOrlita Your argument requires that the machine account being shared is capable of installing software. This is usually not true for shared machine accounts. Consider a library computer. The library almost certainly does not allow the account for guests to install software.
First
CWE + CAPEC = CVE ... proactive security tackles left of the equation, reactive security tackles the right of the equation.
Nice video. :)
08:00 what if attacker can read database but not write?
I would argue that clicking the back button even after logging out is a security vulnerability. Because even though the user deliberately tried to logout here, the session isn't destroyed and the cookie exists. What happens when in a later point of time a session hijacking malware captures this session gaining access to the user's account? Isn't the reason for this vulnerability the website itself and not the user?
"Humpty Dumpty, find my password promptly." - Said the admin, storing passwords in cleartext, including his own.
16:10 why set header instead of including key in request body when POST request?
7:30 - That'll have to be a big change - most sane websites will locally hash your password before it's sent
Holy water water cooling hmmm
Am I time traveling while csurfing
hell yeah brother
Thanks!
What really bakes my noodle is when self-signed certificates end up getting left as the default certificate (usually because the IT engineers are lazy and don't bother to change it to a real certificate).
Sometimes at my job I see a new service handed over to users who subsequently become trained by habit to click the "proceed anyway" button in the browser. Every time this happens a part of me wants to scream into a sweater. This makes for such an easy attack surface for an attacker who sets up a MITM attack to grab some data of value, just because they know the user is just likely to click through the warning message because they've sene that many times before...
oh that is terrible, what kind of companies would have such terrible security practices?
So I can avoid them, of course >_>
2138 für den Algorithmus
This just changes the way I think. Still I have a lot of questions in mind while watching this video. Thanks ❤
I still gotta see the Johnny Depp version, of one of my idols. Hehe
Love the way you explain tricky security topics, When you posted that tweet, I was already on your side, I already knew 'storing passwords in clear text' is not a security issue. But I still watched your video and to be honest, the video was fun to watch.
Are not md5 hashes of the password being sent to the server, instead of the clear text ?
nope, as it wouldn't help anything
@@Random-yj2tr its not anything, you dont send the password which generates the md5 hash
Sometimes I catch myself imagining what it would be like from scratch, taking old paradigms and doing something new. new system and website/sustém & structure models have been created over the last 50 years, With what we learned from them and creating a new network....but even before writing this paragraph I see how stupid it is. 😂😅😢
Other than the great content itself, I just want to say the visuals in this video are lovely! Did you outsource the visual production for this episode?
Dogmatism and security don't go very well together, that's an important thing for every admin/dev to understand.
Cookies do follow same-site policy now - because of Same-Site attribute, which fixed CSRF forever.
I dont get why passwords aren't generally clientside hashed.
Some risks are not fixable within either the limits of price or tech. Great vid btw.
Are you dealing with alot of fake security/bugs reports?
Great Video, amazing scenario and pictures, love it❤
Hashing passwords (at least for comparison) is also important to mitigate timing based atttacks
Kinda unrealistic. I have never seen a real PoC exploit doing that.
Would clear text passwords be considered a vulnerability if someone used social engineering to get an admin or someone who has access to the database to read out the password or wouldn’t social engineering be the vulnerability?
his point is that fundamentally you can only 'trust or not trust' the server in your own threat model, so it makes no difference to you what their internal security is. If they are able to keep plaintext paswords securely, what do you care? Unless you reuse passwords, in which case now their internal security can impact yours.
It's not intended to be literal, keeping plaintext passwords on a server is still just negligently introducing a 'weakness'.
Cool video, great insight!!
Is Alice short for Malice?
based hacker
:) pwned
How would you define security escalation in this context?
Let's say in your initial example, the attacker found a vulnerability that grants access to the passwords. This could be a full read access to the entire database, including private information, but it could also be a simple log file that logs passwords, or maybe an internal service that only as read permissions on the database.
In this example, the method of storing passwords does make a difference, even without adding another website, because now the attacker can escalate the read access into a full write access on the user level.
Or maybe they infiltrated the company, and now leak the passwords, just to cause trouble for the company, without technically breaking any of the defined security boundaries.
These are some of the reasons I would argue to treat this as a vulnerability, as it lets you hop over a security boundary after you managed to get over the first one (in this case read access, or the employment process, or from your example read and write access for other websites).
I would think of a "weakness" more along these lines:
You got access to the password database, got all the passwords. Now the company patches the original vulnerability, but you still have all the passwords and thus still have unauthorized access, the company has no way of patching directly.
This is what I would consider a weakness, and not a vulnerability, because it does not grant any additional access, rather is bad after obtaining access, without hopping over more boundaries after the fact.
I don't think I really got the point you are trying to make, or if it's similar to mine, I disagree with the argument and example.
you are absolutely right! In reality we define security boundaries within security boundaries. And your example of turning read access (leak pw) into write access (login with pw), is then also breaking a boundary.
But I also wanted to make the point that we can define these security boundaries arbitrarily. And that "vulnerability" and "weakness" always have to be looked at with respect to the defined threat model and security boundaries. But your example is indeed generally a reasonable boundary to have in most cases.