Nice they are disabling SSL 3 however actual problem was not SSL 3 which everyone was on notice for years it was actually Google's intentional action to circumvent secure version negotiation in the first place which enabled SSL 3 to continue to be a problem in 2014.
Why can't we on a global basis figure out how to send "researchers" who do this shit to jail?
Again, you can't do anything for idiots who use permutations of dictionary words. "11elephant82" has about 5 symbols worth of entropy. Pathetic.
The world is full of "idiots" otherwise known as people who have better things to do then remember things they are either incapable or lack sufficient motivation to remember.
For a solution to have value to real people in the real world it can only cost as much in time/money/convenience as people are willing to spend/accept.
Decades of experience makes it crystal clear too many people reject secure passwords and nothing we do or say will ever change that... Calling everyone names or blaming users for their poor choice of passwords after a server compromise is not only worthless waste of time that helps nobody but ignores the fact the systems compromise = epic system/administrator failure + blaming the victim. When you get hacked it isn't the users fault so what business do you have asking more of them to hedge against compromise that should not occur in the first place?
If you use a secret key, it needs to be loaded into memory, as does the password database. Guess what?
No shit. You can still create systems with high security with physical separation of concerns. Here is an example architecture:
Application server + database server teaming with millions of reversibly encrypted passwords.
Separate specialized authenticator server with encryption key and separate trust relationship to application server.
User authenticates using zero knowledge proof method... authentication material passed directly from user, thru application stack to authenticator... authenticator looks up password in application database, completes mutual identity verification and sends approval token to application stack.
The only way compromise of credentials occurs in the above scenario is if the authenticator server which does nothing except authenticate is compromised. Even if the application and data stacks are fully compromised user credentials are still safe for all the good that does.
If the key isn't directly accessible, that means that I have to send the encrypted password to a chip and it has to send the decrypted password back. That's plaintext on a wire and in memory. You've already lost. With proper hashing, the password is NEVER in plaintext. You can even run the hash on the client side so it's never transmitted, if you're extra paranoid.
You have it exactly backwards. The authenticator server or hardware only needs to provide a token to the application stack it is not necessary to send clear text passwords anywhere see my example above.
Your example fails because you have three and exactly three options and **NONE** of them work.
1. Send clear text password from user to compare with stored password...This fails as password is required to be transmitted for comparison operation.
2. Use a challenge/response protocol or ship hashes.. This does not work because all such protocols are subject to offline attack while your logging in an easedropper can obtain enough material to run an offline attack and recover credentials.
3. Use a zero knowledge proof of possession to authenticate. This fails because even if you use a hashed password possession of the hash is what is being verified and so having a copy of the hash becomes just as valuable as having a copy of the plaintext.
Alright, I'm through with this troll. Someone else's turn.
Unfortunately in the real world our fairy tales don't get to come true just because we feel empowered to call our users "idiots" and blame them when we ask too much of them or otherwise provide security solutions that are not operationally practical.
My example architecture allows passwords to be only as secure as necessary to prevent *online* attack and clear separation of concerns prevents system compromise from affecting stored credentials regardless of how complex or vulnerable the application and data tiers become.
Looking out the window is the only remaining aspect of flying I look forward to even though it's worthless over most of the flight.
No problem in principal with fake windows and fudge-able camera views... some of the Qatar airways planes had down facing camera views that were exceptionally cool.
Only problem this will all be destroyed by advertising, paywalls and whatever annoyances the marketeers dream up to bleed maximum amount of pennies out of everyone while guaranteeing the most annoying and uncomfortable experience imaginable.
Just look at seating layouts in the fucking videos... with Airlines making seats thinner to squeeze in more rows... we'll see planes like this by the year 20never.
You can't save users who use 'aaaaaa' as a password. No matter what you do. Otherwise,
What about the user who uses 11elephant82 as their password? Are they doomed as well?
you're not going to recover thousands of strong passwords properly salted and hashed. It just isn't going to happen.
It will happen easily. The only thing that isn't *ever* happening is people using strong passwords relative to current and projected cost per transistor.
What are you going to protect with that symmetric key?
The password database? It'd still need to be accessible to the machine holding the database, in order to login.
Yes this is just punting responsibility for keeping a secret. Whether punted to physical keys, operating system keychain, TPM circuits or manual startup inputs all of these things do a better job than tens of thousands to millions of hashes stored in the clear on disk.
Regardless password does not need to be accessible to machine holding the database offering some (small) protection against theft while still being much better than nothing (e.g. hashed passwords with a proven track record of epic fail after epic fail)
Properly salting and hashing is the correct solution. Have you checked your oil lately?
I'm afraid to, daily commute to Langley is taking its toll.
I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password
Occasionally I hear people making statements like this and while practically useful *at best* language is a dangerous assumption.
Additionally complexity of a middle tier just for security sake could well provide additional avenues of attack that may not be available in a globally less complex solution but it all depends on specifics of the implementation.
The reason why *at best* is wrong an attacker able to compromise the application, middle or data tier is almost always able to exert complete control over the environment... just not immediately or on demand.
At any tier an attacker may record data persistently over time compromising user credentials and data as they login and use the system... you don't need to select * from users when attackers already have copies of your data mirrored to them over time or are able to impersonate any number of users.
Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected
Better than delusions of safety.
that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.
Data tier could be made to offer functionally same level of security as an application specific middle tier with view based access and or procedure driven access. Not uncommon to run into systems where user accounts are unable to touch any real table.
Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables.
What is the practical effect on a password list when rainbow tables are taken off the table?
Yes much easier everyone gets that...so what
Say I have a password list with 10000 accounts, they are all salted.. I'm still going to be able to recover thousands of passwords without much effort... still adds up to epic failure with or without salts.
such as encrypting with a 64-bit additional site password, tables wouldn't work. Of course, the same password could have been used to encrypt the entire password file in the first place, but this technique allows the password to be stored in the usual way.
Symmetric keys are a much better idea than the dangerous delusion too many people seem to be subscribing to that clear text storage of salted password hashes affords users any meaningful protection.
In that way, 2-factor encoding works for the password data itself.
Nope this counts only as tweaking integrity of a single factor.
How do you say "Dumb fucks" in mandarin?
"Whatever makes Google a âoekey member of the Defense Industrial Base,â it is not recruitment campaigns pushed out through Google AdWords or soldiers checking their Gmail."
Please describe a 2 factor authentication method that is not susceptible to a man in the middle attack.
Client certificate + password
certificate based smart cards
Specifically, describe a 2FA mechanism that is safe where one channel is completely compromised (Lets say; the Web Page you are "logging in to" is being man in the middled by the Chinese government).
This is not "Prove something doesn't exist", but show me even one example of a mechanism that does exist that is "man in the middle-proof". Seriously.
Too many people seem to be poisoned by the way things are vs how they could be if the proper readily available technology was brought to bear on the problem. Collection of credentials from web forms per your example is breathtakingly stupid way to have your users fall victim to attacks yet it is **everywhere**
For "what you know" use of zero-knowledge key agreement protocols such as TLS-SRP (RFC5054) enable two parties to establish mutual proof of possession without leaking shit and without associated MITM bullshit.
Imagine entering your credentials into a web form and not having to give a shit who is on the other end and without having any SSL certificates.
If the right person is on the other end login succeeds and *both parties* have evidence of the identity of who they are talking to.
If the wrong person was on the other end they don't get *SHIT* not even material for offline attack and the login fails. No certificates or external security mechanisms are required yet they can still be used to further enhance security and practical user experience.
Zero knowledge agreement satisfies "What you know" factor mutually in a secure way without MITM.
Mutual certificate authentication satisfies "What you have" factor in a secure way without MITM.
Each factor above is able to stand on its own feet separately. Each offers mutual evidence of identity.
what do you suppose the word "larger" means, in any context?
Parent said "You cannot over come the columb barrier without sufficient energy."
Yet Muons do it for free as many times as they want before they die or "stick" by virtue of being Muons. This is real cold fusion no crackpottery required.
The production of Muons and assorted details surrounding barriers to useful functioning fusion reactors has zip to do with parents inaccurate comment.
you appear to be clueless around security.
I openly admit to being clueless around everything. You still have to support your arguments.
2FA is not a mitigation against man in the middle. It about raising the confidence level of the identity of the person who initiated the authentication.
Authentication is establishing proof of identity. Over networks this requires strong crypto and guarding of pre-established basis of trust specific to each factor.
There is no way around this basic truth. Number of factors involved is irrelevant.
Just because Google does x or old RSA fobs did y or some bank did z does not make those schemes secure. They may represent practically useful tradeoffs to some subset of the real world yet when your adversary is the Chinese government you quickly appreciate why they are insecure and don't really work.
You can still MITM it depending on other factors implemented, however if you MITM a good 2FA system you only get the one time hijacking of the current session, not the ability to reauthenticate
Is one session not enough to wreak havoc?
and as with many banks they then require a reauth for confirmation of certain off account transactions to help prevent the MITM problem.
I don't think online banking is something that deserves to be held up as an example. At least here in the US the faux second factor schemes allowed to be deployed by many institutions are patently ridiculous and dangerous.
What is secure is entering credentials into a FOB which then performs a cryptographic handshake with the institution. Here each and every factor is strongly protected and at no point is MITM possible unless the physical guard is compromised. Most everything short of the above is noise.
How about building your tech stack so that it can be scaled up/down on-demand? I'm using Rackspace and we have dedicated servers along with cloud servers. I can add or remove cloud servers as needed and also have the load balancers updated.
All this appears to be doing is asking basic questions and executing trivial database lookups. Is there a reason why even a single server should not easily be able to handle world wide demand by itself?
More importantly what is with this failure mode of delay followed by blank screens? Seems like crappy design leading to snowballing collapses.
If you're just doing reads against a database, it's straightforward to add additional replicas (we use MongoDB with replica sets, don't have enough data for sharding yet). If you need to do any processing, then you should build a grid compute system where you can just add additional compute nodes. We're using RabbitMQ along with Celery. Granted, this strategy ignores issues like a saturated network, but our provider is responsible for dealing with that.
Can always count on technology to help us dig even deeper holes for ourselves.
Hard to understood why people continue to use inherently slow and glitchy application stacks to run their sites.
Starting with java and piling on interpreters and frameworks to the point it takes a minimum of 1GB just to start tomcat stack for even trivial applications not even counting data tier something has gone terribly wrong. Once started performance running through mazes of redundant abstraction on top of redundant abstraction leaves precious little room to make up for inevitable developer laziness without maxing out available resources. Isn't just Java yet it seems to be the worst offender.
you should read what you link: Current techniques for creating large numbers of muons require large amounts of energy, larger than the amounts produced by the catalyzed nuclear fusion reactions.
What do you suppose the word "catalyzed" means in the context of muon catalyzed fusion?
Kleeneness is next to Godelness.
