Another thing you can do is to add pain to the second part of it. Attackers want the list of valid usernames, so they can then try to guess or brute force the password. You can put protections in place with that as well, whether they are lockouts or multi-factor authentication, so even if they have a valid username, it's much harder to gain access.

That is certainly a good use-case. One thing you can do is to require something other than a user-chosen string as a username, something like an email address, which should be unique. Another thing you could do, and I admit this is not user-friendly at all, to let them sign up with that user name, but send the user an email letting them know that the username is already used. It still indicates a valid username, but adds a lot of overhead to the process of enumeration.

How would you remediate this? One way could be to have the application pad the responses with a random amount of time, throwing off the noticeable difference.

Sometimes, user enumeration is not as simple as a server responding with text on the screen. It can also be based on how long it takes a server to respond. A server may take one amount of time to respond for a valid username and a very different (usually longer) amount of time for an invalid username.

By default all content inside template strings is escaped. This is great for strings, but not ideal if you want to insert HTML that's been returned from another function (for example: a markdown renderer). Use nanohtml/raw for to interpolate HTML directly.

When processing untrusted user input for (web) applications, filter the input, and encode the output.

The default groups, that we talked about before, like domain users and domain admins are security groups. They're used to grant or deny access to IT resources.

strict-origin: Only send the origin of the document as the referrer when the protocol security level stays the same (e.g. HTTPS→HTTPS), but don't send it to a less secure destination (e.g. HTTPS→HTTP).

There are clever ways around trackers

These creeping changes help us forget how important our privacy is and miss that it’s being eroded.

While stylesheets can be reworked relatively easily with AMP by inlining the CSS, the same is not true for JavaScript. The tag 'script' is disallowed except in specific forms. In general, scripts in AMP are only allowed if they follow two major requirements: All JavaScript must be asynchronous (i.e., include the async attribute in the script tag). The JavaScript is for the AMP library and for any AMP components on the page. This effectively rules out the use of all user-generated/third-party JavaScript in AMP except as noted below.

If you have worked with emails before, the idea of placing a script into an email may set off alarm bells in your head! Rest assured, email providers who support AMP emails enforce fierce security checks that only allow vetted AMP scripts to run in their clients. This enables dynamic and interactive features to run directly in the recipients mailboxes with no security vulnerabilities! Read more about the required markup for AMP Emails here.

Determine if who is using my computer is me by training a ML model with data of how I use my computer. This is a project for the Intrusion Detection Systems course at Columbia University.

It's possible for a document to match more than one match statement. In the case where multiple allow expressions match a request, the access is allowed if any of the conditions is true

If you want rules to apply to an arbitrarily deep hierarchy, use the recursive wildcard syntax, {name=**}

Security rules apply only at the matched path, so the access controls defined on the cities collection do not apply to the landmarks subcollection. Instead, write explicit rules to control access to subcollections

Does a non- negligible failure rate affect the security of TLS?

only the @firebase/testing Node.js module supports mocking auth in Security Rules, making unit tests much easier

Plenty of journalists, attorneys, and activists are equally if not more threatened by so-called evil maid attacks, in which a housekeeper or other stranger has the ability to tamper with firmware during brief physical access to a computer.

See the documentation for HTML::Pipeline’s SanitizationFilter class for the list of allowed HTML tags and attributes. In addition to the default SanitizationFilter allowlist, GitLab allows span, abbr, details and summary elements.

As billions of conversations transition online over the coming weeks and months, the widespread adoption of end-to-end encryption has never been more vital to national security and to the privacy of citizens in countries around the world.

Proponents of this bill are quick to claim that end-to-end encryption isn’t the target. These arguments are disingenuous both because of the way that the bill is structured and the people who are involved.

For a political body that devotes a lot of attention to national security, the implicit threat of revoking Section 230 protection from organizations that implement end-to-end encryption is both troubling and confusing. Signal is recommended by the United States military. It is routinely used by senators and their staff. American allies in the EU Commission are Signal users too. End-to-end encryption is fundamental to the safety, security, and privacy of conversations worldwide.

The EARN IT act turns Section 230 protection into a hypocritical bargaining chip. At a high level, what the bill proposes is a system where companies have to earn Section 230 protection by following a set of designed-by-committee “best practices” that are extraordinarily unlikely to allow end-to-end encryption. Anyone who doesn’t comply with these recommendations will lose their Section 230 protection.

Matrix provides state-of-the-art end-to-end-encryption via the Olm and Megolm cryptographic ratchets. This ensures that only the intended recipients can ever decrypt your messages, while warning if any unexpected devices are added to the conversation.

More than two billion users exchange an unimaginable volume of end-to-end encrypted messages on WhatsApp each day. And unless an endpoint (phone) is compromised, or those chats are backed-up into accessible cloud platforms, neither owner Facebook nor law enforcement has a copy of those encryption keys.

The industry argues that encryption backdoors will result in a weakening of end device security, making it more likely they will be compromised.

As uber-secure messaging platform Signal has warned, “Signal is recommended by the United States military. It is routinely used by senators and their staff. American allies in the EU Commission are Signal users too. End-to-end encryption is fundamental to the safety, security, and privacy of conversations worldwide.”

“End-to-end encryption,” NSA says, “is encrypted all the way from sender to recipient(s) without being intelligible to servers or other services along the way... Only the originator of the message and the intended recipients should be able to see the unencrypted content. Strong end-to-end encryption is dependent on keys being distributed carefully.” So, no backdoors then.

On April 24, the U.S. National Security Agency published an advisory document on the security of popular messaging and video conferencing platforms. The NSA document “provides a snapshot of best practices,” it says, “coordinated with the Department of Homeland Security.” The NSA goes on to say that it “provides simple, actionable, considerations for individual government users—allowing its workforce to operate remotely using personal devices when deemed to be in the best interests of the health and welfare of its workforce and the nation.” Again somewhat awkwardly, the NSA awarded top marks to WhatsApp, Wickr and Signal, the three platforms that are the strongest advocates of end-to-end message encryption. Just to emphasize the point, the first criteria against which NSA marked the various platforms was, you guessed it, end-to-end encryption.

And while all major tech platforms deploying end-to-end encryption argue against weakening their security, Facebook has become the champion-in-chief fighting against government moves, supported by Apple and others.

EFF describes this as “a major threat,” warning that “the privacy and security of all users will suffer if U.S. law enforcement achieves its dream of breaking encryption.”

Once the platforms introduce backdoors, those arguing against such a move say, bad guys will inevitably steal the keys. Lawmakers have been clever. No mention of backdoors at all in the proposed legislation or the need to break encryption. If you transmit illegal or dangerous content, they argue, you will be held responsible. You decide how to do that. Clearly there are no options to some form of backdoor.

While this debate has been raging for a year, the current “EARN-IT’ bill working its way through the U.S. legislative process is the biggest test yet for the survival of end-to-end encryption in its current form. In short, this would enforce best practices on the industry to “prevent, reduce and respond to” illicit material. There is no way they can do that without breaking their own encryption. QED.

Governments led by the U.S., U.K. and Australia are battling the industry to open up “warrant-proof” encryption to law enforcement agencies. The industry argues this will weaken security for all users around the world. The debate has polarized opinion and is intensifying.

One thing that would certainly be a game-changer would be some form of standardized RCS end-to-end encryption that allows secure messages to be sent outside Google Messages.

You should not use a messaging platform that is not end-to-end encrypted, it really is as simple as that.

Such is the security of this architecture, that it has prompted law enforcement agencies around the world to complain that they now cannot access a user’s messages, even with a warrant. There is no backdoor—the only option is to compromise one of the endpoints and access messages in their decrypted state.

The answer, of course, is end-to-end encryption. The way this works is to remove any “man-in-the-middle” vulnerabilities by encrypting messages from endpoint to endpoint, with only the sender and recipient holding the decryption key. This level of messaging security was pushed into the mass-market by WhatsApp, and has now become a standard feature of every other decent platform.

The issue, though—and it’s a big one, is that the SMS infrastructure is inherently insecure, lending itself to so-called “man-in-the-middle attacks.” Messages run through network data centres, everything can be seen—security is basic at best, and you are vulnerable to local carrier interception when travelling.

Despite its opposition, EARN-IT is the clearest threat yet to end-to-end encryption, given this clever twist in pushing the onus onto the platforms to avoid transmitting illegal content, rather than mandating a lawful interception approach.

Putting that risk more simply, the EARN-IT bill is cleverly leaving it to the tech platforms to keep themselves safe—there would be little option other than some form of access to encrypted content, even though it would not be specified in law. Sophos describes this as “the backdoor virus that law enforcement agencies have been trying to inflict on encryption for years.”

On the encryption front, HRW echoes others that have argued vehemently against the proposals—that weakened encryption will “endanger all people who rely on encryption for safety and security—once one government enjoys special access, so too will rights-abusing governments and criminal hackers.” Universal access to encryption “enables everyone, from children attending school online to journalists and whistleblowers, to exercise their rights without fear of retribution.”

Lawmakers and security agencies want legally warranted access to encrypted data. That can’t happen without some form of backdoor in those end-to-end systems.

Just like Blackberry, WhatsApp has claimed that they are end to end encrypted but in fact that is not trueWhatsApp (and Blackberry) decrypt all your texts on their servers and they can read everything you say to anyone and everyoneThey (and Blackberry) then re-encrypt your messages, to send them to the recipient, so that your messages look like they were encrypted the entire time, when in fact they were not

The only messaging app that has been proven, by an independent authoritative agency, is Apple’s Messages app (which uses Apple’s iMessage protocol that is truly end to end encrypted, Apple cannot read any of your texts which means that no one can read any of your texts)

When you make a call using Signal, it will generate a two-word secret code on both the profiles. You will speak the first word and the recipient will check it. Then he will speak the second word and you can check it on your end. If both the words match, the call has not been intercepted and connected to the correct profile

If the EU is set to mandate encryption backdoors to enable law enforcement to pursue bad actors on social media, and at the same time intends to continue to pursue the platforms for alleged bad practices, then entrusting their diplomatic comms to those platforms, while forcing them to have the tools in place to break encryption as needed would seem a bad idea.

First, the recognition that sensitive information needs to be transmitted securely over instant messaging platforms plays into the hands of the privacy advocates who are against backdoors in the end-to-end encryption used on WhatsApp, Signal, Wickr, iMessage and others. The core argument from the privacy lobby is that a backdoor will almost certainly be exploited by bad actors. Clearly, the EU (and others) would not risk their own comms with such a vulnerability.

Although WhatsApp has become the messaging platform of choice for many politicians and civil servants worldwide, there have been enough stories of potential vulnerabilities and hacks to spook people into adopting something else.

“End-to-end encryption” sounds nice — but if anyone can get into your phone’s operating system, they will be able to read your messages without having to decrypt them.

Security agencies use anti-terror efforts to justify planting backdoors. The problem is that such backdoors can also be used by criminals and authoritarian governments. No wonder dictators seem to love WhatsApp: its lack of security allows them to spy on their own people, so WhatsApp continues to be freely available in places like Russia or Iran, where Telegram is banned by the authorities

This is also useful for anyone that doesn't normally have root access but would like to easily become root on your host.

using SSH is likely the best approach because personal access tokens have account level access

Before enabling this, you should ensure jobs are visible to team members only. You should also erase all generated job logs before making them visible again.

Available documentation suggests that ED25519 is more secure.

There is a serious weakness in DSA (which extends to ECDSA) that has been exploited in several real world systems (including Android Bitcoin wallets and the PS3); the signature algorithm relies on quality randomness (bits that are indistinguishable from random); once the PRNG enters a predictable state, signatures may leak private keys. Systems that use ECDSA must be aware of this issue, and pay particular attention to their PRNG.

GanttLab does not store any information: everything runs in your browser. Under the hood, we use localForage to remember the state of the application, which enables great user experience without any security risk. Secured API requests are initiated in your computer's browser, hence coming straight from your local network. Those requests are going directly to the data source you selected (your GitHub or GitLab account) without ever transiting through any other server.

GanttLab does not store any information: everything runs in your browser. Under the hood, we use localForage to remember the state of the application, which enables great user experience without any security risk. Secured API requests are initiated in your computer's browser, hence coming straight from your local network. Those requests are going directly to the data source you selected (your GitHub or GitLab account) without ever transiting through any other server.

Image consumers can enable DCT to ensure that images they use were signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. Enabling DCT is a bit like applying a “filter” to your registry. Consumers “see” only signed image tags and the less desirable, unsigned image tags are “invisible” to them.

In terms of their border dispute, India and China are struggling with what game theorists refer to as a “commitment problem.” Meaning A commitment problem arises when two states, who would be better off in the present if they consented to a mutually beneficial agreement, are unable to resolve their disputes due to different expectations of future strengths, and a consequent inability to commit to future bargaining power or a division of benefits.

Allowing port 80 doesn’t introduce a larger attack surface on your server, because requests on port 80 are generally served by the same software that runs on port 443.

CodeGuard relies upon industry best practices to protect customers’ data. All backups and passwords are encrypted, secure connections (SFTP/SSH/SSL) are utilized if possible, and annual vulnerability testing is conducted by an independent agency. To-date, there has not been a data breach or successful hack or attack upon CodeGuard.

Certified Ethical Hacker

However, it's possible to enforce both a whitelist and nonces with 'strict-dynamic' by setting two policies:

Amazon Macie is a security service that uses machine learning to automatically discover, classify, and protect sensitive data in AWS.

sadness.js will not load, however, as document.write() produces script elements which are "parser-inserted".

If a user clicks on that button, the onclick script will not execute. This is because the script did not immediately execute and code not interpreted until the click event occurs is not considered part of the content script, so the CSP of the page (not of the extension) restricts its behavior. And since that CSP does not specify unsafe-inline, the inline event handler is blocked.

Remember that nonces must be regenerated for every page request and they must be unguessable.

I will need to find a workaround for one of my private extensions that controls devices in my home network, and its source code cannot be uploaded to Mozilla because of my and my family's privacy.

While there are security benefits to disallowing unsigned extensions by default, it is not clear why there is no option to turn off this behavior, perhaps by making it configurable only with administrator rights.

It would be best to offer an official way to allow installing local, unsigned extensions, and make the option configurable only by root, while also showing appropiate warnings about the potential risks of installing unsigned extensions.

They don't have to host the extension on their website, but it's absolutely and utterly unacceptable for them to interfere with me choosing to come to github and install it.

I appreciate the vigilance, but it would be even better to actually publish a technical reasoning for why do you folks believe Firefox is above the device owner, and the root user, and why there should be no possibility through any means and configuration protections to enable users to run their own code in the release version of Firefox.

I do not understand what is the threat model of not allowing the root user to configure Firefox, since malware could just replace the entire Firefox binary.

I appreciate the vigilance, but it would be even better to actually publish a technical reasoning for why do you folks believe Firefox is above the device owner, and the root user, and why there should be no possibility through any means and configuration protections to enable users to run their own code in the release version of Firefox.

I will need to find a workaround for one of my private extensions that controls devices in my home network, and its source code cannot be uploaded to Mozilla because of my and my family's privacy.

We must consider introducing sensible default options in Firefox, while also educating users and allowing them to override certain features, instead of placing marginal security benefits above user liberties and free choice.

potentially dangerous APIs may only be used in ways that are demonstrably safe, and code within add-ons that cannot be verified as behaving safely and correctly may need to be refactored

Add-ons are not allowed to contain obfuscated code, nor code that hides the purpose of the functionality involved. If external resources are used in combination with add-on code, the functionality of the code must not be obscured.

I'm really tired with mozilla,everything good about them is going away,I don't think they are security or privacy focused anymore and waterfox is a nice alternative to firefox.

Mozilla can still block distribution of the extension, even when not distributed via ADO. It is not possible for us to provide Mozilla the unminified JavaScript source files for Google’s and Microsoft’s translation widgets. This is a risk because Mozilla can demand such.

Mozilla does not permit extensions distributed through https://addons.mozilla.org/ to load external scripts. Mozilla does allow extensions to be externally distributed, but https://addons.mozilla.org/ is how most people discover extensions. The are still concerns: Google and Microsoft do not grant permission for others to distribute their "widget" scripts. Google's and Microsoft's "widget" scripts are minified. This prevents Mozilla's reviewers from being able to easily evaluate the code that is being distributed. Mozilla can reject an extension for this. Even if an extension author self-distributes, Mozilla can request the source code for the extension and halt its distribution for the same reason.

If you delegate all your IT security to the InfoSec, they will come up with draconian rules

Don’t share any private, identifiable information on social media It may be fun to talk about your pets with your friends on Instagram or Twitter, but if Fluffy is the answer to your security question, then you shouldn’t share that with the world. This may seem quite obvious, but sometimes you get wrapped up in an online conversation, and it is quite easy to let things slip out. You may also want to keep quiet about your past home or current home locations or sharing anything that is very unique and identifiable. It could help someone fake your identity.

Don’t share vacation plans on social media Sharing a status of your big trip to the park on Saturday may be a good idea if you are looking to have a big turnout of friends to join you, but not when it comes to home and personal safety. For starters, you have just broadcasted where you are going to be at a certain time, which can be pretty dangerous if you have a stalker or a crazy ex. Secondly, you are telling the time when you won’t be home, which can make you vulnerable to being robbed. This is also true if you are sharing selfies of yourself on the beach with a caption that states “The next 2 weeks are going to be awesome!” You have just basically told anyone who has the option to view your photo and even their friends that you are far away from home and for how long.

I've written before about the attitude of people with titles like "Marketing Manager" where there can be a myopic focus on usability whilst serious security incidents remain "a hypothetical risk".

There will be those within organisations that won't be too keen on the approaches above due to the friction it presents to some users.

This has a usability impact. From a purely "secure all the things" standpoint, you should absolutely take the above approach but there will inevitably be organisations that are reluctant to potentially lose the registration as a result of pushing back

I'm providing this data in a way that will not disadvantage those who used the passwords I'm providing.

As such, they're not in clear text and whilst I appreciate that will mean some use cases aren't feasible, protecting the individuals still using these passwords is the first priority.

you could even provide an incentive if the user proactively opts to change a Pwned Password after being prompted, for example the way MailChimp provide an incentive to enabled 2FA:

Perhaps, for example, a Pwned Password is only allowed if multi-step verification is enabled. Maybe there are certain features of the service that are not available if the password has a hit on the pwned list.

A middle ground would be to recommend the user create a new password without necessarily enforcing this action. The obvious risk is that the user clicks through the warning and proceeds with using a compromised password, but at least you've given them the opportunity to improve their security profile.

The Authenticity Token is a countermeasure to Cross-Site Request Forgery (CSRF). What is CSRF, you ask? It's a way that an attacker can potentially hijack sessions without even knowing session tokens.

Rails does not issue the same stored token with every form. Neither does it generate and store a different token every time. It generates and stores a cryptographic hash in a session and issues new cryptographic tokens, which can be matched against the stored one, every time a page is rendered.

Since the authenticity token is stored in the session, the client cannot know its value. This prevents people from submitting forms to a Rails app without viewing the form within that app itself. Imagine that you are using service A, you logged into the service and everything is ok. Now imagine that you went to use service B, and you saw a picture you like, and pressed on the picture to view a larger size of it. Now, if some evil code was there at service B, it might send a request to service A (which you are logged into), and ask to delete your account, by sending a request to http://serviceA.com/close_account. This is what is known as CSRF (Cross Site Request Forgery). If service A is using authenticity tokens, this attack vector is no longer applicable, since the request from service B would not contain the correct authenticity token, and will not be allowed to continue.

A common mistake is to see those escaped angle brackets, and "improve" the helper by making everything html_safe:

You don't "sanitize your output" you encode it for proper context within the application it is being presented. You encode the output for HTML, HTML Attribute, URL, JavaScript

When you output the data, you know the use case of the data. This knowledge allows you to safely sanitize the output data accordingly.

I would call this output encoding instead of sanitization

1- Validation: you “validate”, ie deem valid or invalid, data at input time. For instance if asked for a zipcode user enters “zzz43”, that’s invalid. At this point, you can reject or… sanitize. 2- sanitization: you make data “sane” before storing it. For instance if you want a zipcode, you can remove any character that’s not [0-9] 3- escaping: at output time, you ensure data printed will never corrupt display and/or be used in an evil way (escaping HTML etc…)

What Is Input Validation and Sanitization? Validation checks if the input meets a set of criteria (such as a string contains no standalone single quotation marks). Sanitization modifies the input to ensure that it is valid (such as doubling single quotes).