now browsing by tag


Chrome 80 encryption change blocks AZORult password stealer – Naked Security

Source: National Cyber Security – Produced By Gregory Evans

Evidence is emerging that a barely noticed change made to Chrome 80, released on 4 February, might have disrupted the hugely successful data and user profile stealing malware AZORult.

AZORult first appeared in 2016, since then it has been used to thieve huge amounts of information from victims, including everything from cryptocurrency data, passwords, web browsing history and cookies, to credentials for FTP clients, desktop Telegram, and Skype chats.

You name it, AZORult will try to steal it, often posing as legitimate software such as the installer for ProtonVPN.

The malware went into a relative decline in 2018. And now, according to research by Israeli security company Kela, chatter on crime forums suggests cybercriminals believe that Chrome 80’s move to encrypt locally saved passwords and cookies using AES-256 has killed the malware’s attempts to steal data for good.

When running on Windows, Chrome previously relied on Microsoft’s systemwide Data Protection API (DPAPI), which has proved susceptible to popular credential cracking tools such as Mimikatz.

“All the older cracked versions of different stealers are finished,” Kela translates a Russian language commenter on a crime forum as having said.

Data Encryption on Android with Jetpack Security

Source: National Cyber Security – Produced By Gregory Evans

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Illustration by Virginia Poltrack

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples.

The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets.

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user’s data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection.

Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink.

Key Generation

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object.

Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices.

val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices.

Important options:

  • userAuthenticationRequired() and userAuthenticationValiditySeconds() can be used to create a time-bound key. Time-bound keys require authorization using BiometricPrompt for both encryption and decryption of symmetric keys.
  • unlockedDeviceRequired() sets a flag that helps ensure key access cannot happen if the device is not unlocked. This flag is available on Android Pie and higher.
  • Use setIsStrongBoxBacked(), to run crypto operations on a stronger separate chip. This has a slight performance impact, but is more secure. It’s available on some devices that run Android Pie or higher.

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present.

// Custom Advanced Master Key
val advancedSpec = KeyGenParameterSpec.Builder(
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
).apply {
    setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {

val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec)

Unlocking time-bound keys

You must use BiometricPrompt to authorize the device if your key was created with the following options:

  • userAuthenticationRequired is true
  • userAuthenticationValiditySeconds > 0

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user.

BiometricPrompt code to unlock time-bound keys

// Activity.onCreate

val promptInfo = PromptInfo.Builder()
    .setDescription("Would you like to unlock this key?")

val biometricPrompt = BiometricPrompt(
    this, // Activity

private val authenticationCallback = object : AuthenticationCallback() {
        override fun onAuthenticationSucceeded(
            result: AuthenticationResult
        ) {
            // Unlocked -- do work here.
        override fun onAuthenticationError(
            errorCode: Int, errString: CharSequence
        ) {
            super.onAuthenticationError(errorCode, errString)
            // Handle error.

To use:

Encrypt Files

Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it’s not possible to reorder.

val secretFile = File(filesDir, "super_secret")
val encryptedFile = EncryptedFile.Builder(
    .setKeysetAlias("file_key") // optional
    .setKeysetPrefName("secret_shared_prefs") // optional

encryptedFile.openFileOutput().use { outputStream ->
    // Write data to your encrypted file

encryptedFile.openFileInput().use { inputStream ->
    // Read data from your encrypted file

Encrypt SharedPreferences

If your application needs to save Key-value pairs – such as API keys – JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to.

Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups.

).edit {
    // Update secret values

More Resources

FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security.

Happy Encrypting!

Source link

The post Data Encryption on Android with Jetpack Security appeared first on National Cyber Security.

View full post on National Cyber Security

#infosec | Apple Dropped iCloud Encryption Plans After FBI Complaint: Report

Source: National Cyber Security – Produced By Gregory Evans

Apple dropped plans to offer end-to-end encrypted cloud back-ups to its global customer base after the FBI complained, a new report has claimed.

Citing six sources “familiar with the matter,” Reuters claimed that Apple changed its mind over the plans for iCloud two years ago after the Feds argued in private it would seriously hinder investigations.

The revelations put a new spin on the often combative relationship between the law enforcement agency and one of the world’s biggest tech companies.

The two famously clashed in 2016 when Apple refused to engineer backdoors in its products that would enable officers to unlock the phone of a gunman responsible for a mass shooting in San Bernardino.

Since then, both FBI boss Christopher Wray, attorney general William Barr and most recently Donald Trump have taken Apple and the wider tech community to task for failing to budge on end-to-end encryption.

Silicon Valley argues that it’s impossible to provide law enforcers with access to encrypted data in a way which wouldn’t undermine security for hundreds of millions of law-abiding customers around the world.

They are backed by world-leading encryption experts, while on the other side, lawmakers and enforcers have offered no solutions of their own to the problem.

Apple’s decision not to encrypt iCloud back-ups means it can provide officers with access to target’s accounts. According to the report, full device backups and other iCloud content was handed over to the US authorities in 1568 cases in the first half of 2019, covering around 6000 accounts.

Apple is also said to have handed the Feds the iCloud backups of the Pensacola shooter, whose case sparked another round of calls for encryption backdoors from Trump and others.

It’s not 100% clear if Apple dropped its encryption plan because of the FBI complaint, or if it was down to more mundane usability issues. Android users are said to be able to back-up to the cloud without Google accessing their accounts.


#infosec #itsecurity #hacking #hacker #computerhacker #blackhat #ceh #ransomeware #maleware #ncs #nationalcybersecurityuniversity #defcon #ceh #cissp #computers #cybercrime #cybercrimes #technology #jobs #itjobs #gregorydevans #ncs #ncsv #certifiedcybercrimeconsultant #privateinvestigators #hackerspace #nationalcybersecurityawarenessmonth #hak5 #nsa #computersecurity #deepweb #nsa #cia #internationalcybersecurity #internationalcybersecurityconference #iossecurity #androidsecurity #macsecurity #windowssecurity

Source link

The post #infosec | Apple Dropped iCloud Encryption Plans After FBI Complaint: Report appeared first on National Cyber Security.

View full post on National Cyber Security

#cybersecurity | #hackerspace | Encryption Wars, Part IV: Barr vs. Big Tech

Source: National Cyber Security – Produced By Gregory Evans

Will AG Barr succeed in his fight to empower the U.S. government with the ability to break strong encryption against tech companies?

U.S. Attorney General Bill Barr once again is decrying the fact that tech companies are proposing strong security standards for data at rest and data in transmission. By using encryption to protect data, the nation’s chief law enforcement official explains, companies will enable terrorists, pedophiles and mass murderers to communicate without fear that government officials, armed with warrants, will be able to listen in on their communications, read their emails and direct messages and discover the contents of their cloud applications and hardware devices. It’s time to empower law enforcement to break strong encryption—of course, with a warrant. Because, in the same breath, Barr also decries what he calls systematic abuse of the warrant application process through multiple layers of the FBI and U.S. Department of Justice (DoJ), through two political administrations, in one of the most sensitive and highly regulated and supervised criminal and national security investigations.

Trust us. We’re the FBI.

AG Barr added another arrow in his quiver to attempt to compel tech companies to comply with his demand that they make the internet less secure: removing their immunity. Section 230 of the Communications Decency Act (CDA) provides that “carriers” of information are not “publishers” of that information when posted by third parties. There are good and bad consequences to this policy decision. The good is that tech giants are not required to read and censor every internet posting, every instant message or direct message, every comment and every website. It means a more free and open sharing of opinions and a more free and open internet in general. The bad is that tech giants are not required to read and censor every internet posting. It means that individuals defamed or injured by such postings, who suffer loss of reputation or who are doxed or stalked online, who are victims of revenge porn, fake news or trolling attacks have little recourse both against the tech companies that disseminate and “broadcast” (in the general sense of making available to the public) the injurious content and against the actual creator or poster of the content, who can generally hide behind various legal and technological shields of anonymity.

Section 230 immunity is a great boon to tech giants who want the benefits of collecting massive amounts of information from individuals about their use of these services without the muss and fuss of having to police the trolls. That’s someone else’s problem.

So now the DoJ and Congress are threatening to remove Section 230 immunity (or to limit it in some fashion). Among the “concessions” the administration wants is for the tech giants to give some additional leeway to law enforcement and the intel community on the issue of data encryption. “Dat’s a nice little free and open internet youze got there … it would be a shame should sumthing happen to it …”

Both Section 230 and the so-called “going dark” problem present nuanced and difficult public policy choices. Weaken encryption to go after child molesters and you invite more hacking of banking systems, less privacy and more abuse even by law enforcement and the intel community. Make crypto unbreakable and you destroy accountability—sort of. Give absolute 230 immunity and there’s little incentive to create safe spaces on the internet or to provide information from which users can be held accountable for their actions. Remove immunity and the quantity and quality and openness of the internet is destroyed. Conflate the two policies and the problems are exponentially more difficult to solve.

I have written on the “going dark” problem many times before, and I am firmly in the camp of a stronger, safer and more secure internet without back doors for one government or another. The perception that the Huawei technology behind our 5G backbone is riddled with actual or potential back doors was enough for Congress and the FCC to demand that the infrastructure be ripped out root and stem. Imagine the international reaction if such “back doors” were perceived to be an integral part of communications, telecom and OSes? Not pretty.

There are plenty of reasons and ways to regulate big tech. These may not be the best ones.

Source link

The post #cybersecurity | #hackerspace |<p> Encryption Wars, Part IV: Barr vs. Big Tech <p> appeared first on National Cyber Security.

View full post on National Cyber Security

#deepweb | Why encryption is failing us

Source: National Cyber Security – Produced By Gregory Evans Encryption is viewed by many as “bullet proof” technology. Along with antivirus software, organisations swear by it, and consumers feel overly confident knowing that their recent transactions and personal data are encrypted. Despite the confidence around this “go-to” technology, time has shown that encryption is just […] View full post on AmIHackerProof.com

Is encryption rendering your firewall irrelevant? – Sophos News

Source: National Cyber Security – Produced By Gregory Evans

Transport Layer Security (TLS) is the encryption standard used on the internet today – the terms SSL and TLS are often used interchangeably but Secure Sockets Layer (SSL) is an old standard that has been eclipsed by TLS. So, although the more common term is still SSL, just know that most people mean TLS when they say SSL.

Encryption provides privacy not security

TLS is designed to provide confidentiality and authenticity by encrypting the communication between two parties and verifying the server is who it claims to be, based on its certificate and who issued it.

The lock symbol in your browser indicates the connection is encrypted.

TLS encryption does NOT provide any security or assurance of the content. So when someone says their connection to the server is secure, they really only mean it’s secure from eavesdropping and that the identity of the server is confirmed.

You can have a perfectly valid encrypted and ‘secure’ connection to a site hosting malicious payloads… which is why inspection of this encrypted traffic is so important.

TLS inspection is not easy

The problem is that TLS is a very complex protocol with different certificates having to be exchanged, as well as negotiation over cipher suites to be used to determine how the connection should be encrypted.

There are also, of course, several TLS versions, and many applications and web services do things differently. Despite having rigorous standards, this makes it very possible for things to be incompatible.

This presents enormous challenges for any security solution that attempts to inject itself into this process for the purpose of inspecting and securing the content that is exchanged.

On top of all the technical complexity, there are policy decisions that need to be made. Not all SSL traffic can or should be treated the same. It’s a balancing act: You have to balance privacy, performance, security and compliance. Some traffic, like banking and finance, should not be inspected and some traffic cannot be inspected.

Encrypted traffic volume is approaching 100%

For many good reasons, most internet connections are now fully encrypted. In fact, on most platforms over 80% of web sessions are now encrypted according to the Google Transparency Report.

Has encryption rendered your firewall irrelevant?

Encryption is great for privacy, yes. But, it is also creating an enormous blind spot for most organizations, where their current firewalls are not up to the task of inspecting great volumes of encrypted traffic.

In effect, TLS encryption has rendered most firewalls irrelevant and useless as they no longer have insight into the majority of traffic passing through the network.

The real danger is the threats hiding in encrypted traffic

With the explosive growth in TLS encryption in recent years, it’s probably no surprise that hackers are catching onto this trend and leveraging it to help get malware on your network undetected and keep it there.

In fact, according to SophosLabs, about 1/3rd of malware and unwanted applications are using TLS, to stealthily get on your network and communicate once there, all in the interest of remaining undetected.

Why most organizations are powerless to do something

As I outlined earlier, TLS is complex and resource intensive.

It’s extremely expensive to invest in the R&D necessary to properly inspect TLS encrypted traffic at the firewall, in an efficient and effective way. As a result, most firewall products simply aren’t up to the task of inspecting the current volume of encrypted traffic passing through them.

Most network admins have been forced to accept the risk of threats and non-compliance due to serious performance limitations. Enabling TLS inspection is just too costly in terms of the performance impact.

On top of that, poor inspection implementations that don’t support the latest standards result in downgraded security, which opens up vulnerabilities, or simply break a lot of websites, resulting in a terrible user experience.

This situation is creating conditions for a perfect storm.

There has to be a better way

And, there is!

Over the last few years, we’ve been investing heavily in solving the problem with TLS inspection. The result of all that effort is the new Xstream Architecture in XG Firewall v18.

It offers a new ground-up solution to eliminating that vast blind spot, without all the performance and user experience compromises that have plagued other solutions.

It delivers:

  • High performance – a light weight engine with high connection capacity
  • Top security – supporting TLS 1.3 and all modern cipher suites
  • Inspection of all traffic – being application & port agnostic
  • A great user experience – with extensive interoperability to avoid breaking the internet
  • Powerful policy – offering the perfect balance of performance, privacy and protection
  • Unmatched visibility – into your encrypted traffic flows and any errors

There’s no longer a need to run blind. Return your firewall to relevance and start inspecting the traffic flowing through it.

You can try the new Xstream SSL Inspection in XG Firewall v18 as part of the early access program. Get started today! All our licensed XG Firewall customers get this great new capability at no charge.

Watch this video to learn more about how it works:

Source link

The post Is encryption rendering your firewall irrelevant? – Sophos News appeared first on National Cyber Security.

View full post on National Cyber Security

Encryption #vital to #protecting our #data in the #modern #age

As some law enforcement officials would like to have you believe, choosing to digitally arm yourself for defensive purposes does not make you a criminal. For many years now, arguments have been made over the extent an individual should be able to, however no serious case to eliminate this ability had been made — until now.

At a recent speech, CIA Director Mike Pompeo touched on the traditional national security topics, but then he ventured into the surreal. The CIA director offered, “Cyber is another vector — it’s not a threat of its own, but it is a means by which many non-nation-state actors can inflict incredible costs on the United States of America.” The alarming part is when he attaches the proliferation of end-to-end encryption as part of the challenges his agency faces when tracking these non-nation state terrorists.

To be clear, the head of America’s intelligence agency is saying that encryption is part of the problem for law enforcement in fighting the bad guys. Though this shouldn’t be a shock, as Congressman Pompeo once wrote, “The use of strong encryption in personal communications may itself be a red flag.”

For anyone wondering why an individual would consider using encryption in their daily lives, let me illustrate what this means. In today’s connected world, the reason you read so many stories about cyber-crimes committed by two-bit hackers is because they are trying to steal your credit card number, or enough personal information to commit identity theft. They are afforded this ability because of your lack of encryption. In Free states, encryption is used to protect people from cyber criminals. In the more oppressive countries, encryption is used as a tool to break through firewalls to gain access to an uncensored free and open internet. In many cases, it is the users’ only interaction with the outside world that hasn’t been sanctioned by their government.

Criminalizing encryption is the elimination of our right to self-protect from privacy thieves. The hard truth is encryption exists to protect our right to free speech online here and abroad.

The CIA is far from being a lone voice in the woods, as Deputy U.S. Attorney General Rod Rosenstein is a long-time encryption critic. He’s used every criminal event of national interest as a platform to attack personal digital security as part of a tech conspiracy to thwart law enforcement’s effort to tackle crime. While personal encryption is effective against hackers, governments by and large are getting every byte of your data they want.

Perhaps the deputy attorney general’s most naïve position has been to demand tech companies create strong consumer encryption, but also offer law enforcement backdoor access to your device’s data. This is coming from the same government that maintains a monstrous data center farm in Utah to collect and maintain every bit and byte of digital communications generated globally. The NSA is charged with overseeing the $1.2 billion facility, and promises to only use it for terrorist connected cases. However, as we’ve noted in the past, perhaps the greatest leakers of secure and private information is the very intelligence community that is charged with shielding us from those evildoers. Aside from the ridiculous expectation of an encryption-lite option, a Stanford University cryptographer made it abundantly clear in a recently released paper, and assures us that this type of “securely accessible” encryption does not exist.

Due to the mounting law enforcement worldview of effective encryption as a platform used primarily by criminals, and the general decline of privacy, the ability to maintain some shred of confidentiality is now accompanied with stigma, as well as a price tag that is growing out of reach to the average consumer. Sadly, the United States has been moving toward becoming a country that enjoys cheap luxuries, but expensive necessities. Privacy is no longer a right in the digital realm, but a commodity to be bartered without the creator’s consent.

This exposure has lead everyday consumers to seriously consider options that help shield their data. One pragmatic piece to the privacy solution would be to minimize the chances of such data theft concerns by allowing competition to reign in the ISP markets once again in the form of “open access,” which would restrict network infrastructure providers to operating within prescribed limits. Removing the government protected oligarchy that rules America’s current internet access options would allow consumers to choose providers that consider privacy a priority to their customers, rather than a self-entitled byproduct.

Privacy and access to effective encryption should be a fundamental right. The overtures by the government have forced consumers to consider privacy enabling applications — but it shouldn’t be that way. The right to self-protect should not come with an over-burdensome price tag, and certainly not with an assumption of guilt. There is a strong and proven legislative path forward in allowing consumers to protect ourselves, and it begins with open access.


The post Encryption #vital to #protecting our #data in the #modern #age appeared first on National Cyber Security Ventures.

View full post on National Cyber Security Ventures

How #quantum #computing could create #unbreakable #encryption and save the #future of #cybersecurity

Source: National Cyber Security – Produced By Gregory Evans

A new breakthrough in quantum computing may mean quantum key distribution (QKD) is on its way toward being a practical cybersecurity protocol.

Researchers at Duke University, The Ohio State University, and Oak Ridge National Laboratory have announced in the latest issue of Science Advances that they’ve increased the speed of QKD transmission by between five and 10 times the current rates.

Up until this latest breakthrough, which is delivering megabit/second rates, speeds were restricted to between tens to hundreds of kilobits a second.

What is quantum key distribution?

It sounds like something straight out of science fiction, but quantum key distribution is reality, and it could be protecting your data before you know it.

QKD uses photons—particles of light—to encode data in qubits, or quantum bits. The qubits are transmitted to a sender and recipient as an encryption key, and here’s where things get crazy: The transmission channels don’t need to be secure.

QKD’s whole purpose rests on quantum indeterminacy, which states that measuring something affects its original state. In the case of QKD, measuring photonic qubits affects their encoding, which allows the sender and recipient to immediately know if a hacker is trying to crack their quantum encryption key.

That means, theoretically at least, that QKD would be a perfect encryption: Any attempts to crack it would immediately be noticed and keys could be changed.

Making QKD practical for cybersecurity

The breakthrough made by the Duke research team came from being able to pack more data onto a single photon. The trick was learning to adjust the time at which the photon was released, along with adjusting the phase of the photon, causing it to be able to hold two bits of information instead of just one.

What makes the new system developed by the researchers even more amazing is that they were able to do it with nothing but commercially available telecommunication hardware, save the single-photon detector.

“With some engineering,” said Duke graduate student Nurul Taimur Islam, “we could probably fit the entire transmitter and receiver in a box as big as a computer CPU.”

Islam and his research partners say that hardware imperfections render their QKD system less than hack-proof, but their research continues to incorporate hardware shortcomings to make up for them.

“We wanted to identify every experimental flaw in the system, and include these flaws in the theory so that we could ensure our system is secure and there is no potential side-channel attack,” Islam said.

While it’s likely to take some time to emerge from the research phase and become a practical tool, this latest QKD breakthrough gives cybersecurity a leg up on cybercriminals.

As quantum computing becomes accessible, the likelihood of it being used to obliterate current forms of encryption increases, making the development of practical QKD essential. This should come as good news to anyone concerned about the current, and future, state of cybersecurity.

The post How #quantum #computing could create #unbreakable #encryption and save the #future of #cybersecurity appeared first on National Cyber Security Ventures.

View full post on National Cyber Security Ventures

Australia: Shelve Proposed Law to Weaken Encryption

Source: National Cyber Security – Produced By Gregory Evans

The Australian government should not force technology companies to weaken the security of their products or to subvert encryption, Human Rights Watch said last week in a letter to Prime Minister Malcolm Turnbull. That strategy would undermine cybersecurity for all users and would not stop determined criminals from using encryption….

The post Australia: Shelve Proposed Law to Weaken Encryption appeared first on National Cyber Security Ventures.

View full post on National Cyber Security Ventures

IBM plans to thwart hackers with a cover-all encryption system

more information on sonyhack from leading cyber security expertsSource: National Cyber Security – Produced By Gregory Evans IBM Z is the company’s answer to the internet-old problem of secure data storage Hackers are everywhere. Some are simply looking for opportunistic cash-grabs while others want to access top-secret data and share it amongst nefarious networks. There are also “hacktivists” that look to steal data […] View full post on AmIHackerProof.com | Can You Be Hacked?