Someone keeps using my email address. What to do? I have had a GMail ever since it was created, so it's an email address that is easy to remember, but also easy for somebody else to get confused with.

Since I'm not going to post my email address here, I'll put the format for it which is [first name][2 digit number]@gmail.com. Because of this, somebody unknowingly (or knowingly) has been using my email address to sign up for all sorts of things and now my inbox is even more full of junk.

I was able to get his information (name, address, etc) from all the places that he's signed up for using my email, but I have been unable to find him to get a hold of him about this matter. I have also had to get a hold of all sorts of places that he's used my email to tell them that he has it wrong and all they will do is remove my email and won't try to tell him he's got the wrong email address.

It is starting to become very time consuming and annoying that I have to get all these emails and have to get it removed. If I just ignore/delete these emails, then there's just going to be more and more of them.

I'm wondering if anyone has had this happen before and if there's any solution for this sort of thing?

This is not very uncommon. Unfortunately you have no single solution, unless the individual is in the same locale as you (in which case you may be able to take legal action if he is causing you to incur costs)

Generally, there is no technical solution, as this is a human problem. They could be doing it deliberately, as Pacerier suggests, or they may just think that they have the email address right.

Online services typically just let people signup with whatever address they give. The better ones require email validation - so as long as you don't validate the email, those ones shouldn't cause you any problems.

In summary - you can try and educate the guy, but basically you'll just need to ignore the issue.


Sending Private Keys, does it make sense? There's some logic that I'm not following whenever my organization sets up VMs for SSH access. Perhaps someone can help me understand.

Our process is currently as follows

Generate Keypair on Linux Server (EC2 instance)
Copy id_rsa (the private key) to Windows system.
Use Putty's keygen to convert to generate a PPK key file from that private key. Then connect to putty with that key file.

But wouldn't it be more secure to generate the keys on the Windows system, connect to our server and add the windows public key to the authorized_key file? Am I missing something?

You are right in that it would be more secure to generate and keep the private key only on the windows system and share only the public key with other systems.

But depending on your specific environment and users it might be more easy and comfortable but still considered secure enough to generate the key the way you describe. There is no such thing as absolute security or even best security - it is always a compromise between performance and usability on one side and the risks on the other side. As long as the risks are small enough (which depend on the actual environment and use case) one might well use the more comfortable way.


Caching personal data: GDPR There are requests in my web application that contain "personal data" (name, postal code, phone number, date of birth etc). I would like to know what caching controls are advisable. I am using HTTPS.

This question Best practice for caching sensitive data has been asked before.

It looks like I should be using Cache-Control: private if I'm not very paranoid..

  Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

...and Cache-Control: no-store if I am very paranoid.

And by "paranoid" I mean: "thinking keeping personal data in the user-agent's single user cache is a bad idea".

I think keeping personal data in a user-agents single user cache is basically fine. It looks like opinion is divided on this, and my opinion is from about 10 minutes of googling. Also, I don't think the linked question really provides a way of making an informed decision here. So I'd like to hear if people disagree.

Do I need to change my approach here because of GDPR?

If I had asked the same question for "Sensitive Personal Data" does anything change?

The law is about what you are allowed to store and targets your infrastructure. And the law is intended to give the user control over his data.

The client cache belongs to the client's infrastructure in any reasonable definition and already is under control of the user.

This may be interpreted differently when you try things like supercookies which stay even when history is deleted or other sneaky tricks, but as long as you're just speaking about the usual client cache this is nothing you're actively storing and nothing you have direct access to.

But be aware of other caches. Maybe your load balancer caches responses with a cache header which allows caching. Then people can argument that you still have data about them stored. It may not be too easy to access, but it is there, could be accessed or may leak when you're hacked.

Disclaimer: I am not a lawyer and you might want to find one. Currently nobody knows for sure what will actually get you sued and what not.


If Yahoo can get hacked , how can we secure our small websites? Law enforcement provided Yahoo in November 2016 with data files that a
  third party claimed was Yahoo user data. We analyzed this data with
  the assistance of outside forensic experts and found that it appears
  to be Yahoo user data. Based on further analysis of this data by the
  forensic experts, we believe an unauthorized third party, in August
  2013, stole data associated with more than one billion user accounts.
  Yahoo has not been able to identify the intrusion associated with this
  theft. We believe this incident is likely distinct from the incident
  we disclosed on September 22, 2016. We are notifying potentially
  affected users and have taken steps to secure their accounts,
  including requiring users to change their passwords. Yahoo has also
  invalidated unencrypted security questions and answers so that they
  cannot be used to access an account.

Yahoo says more than one billion accounts got hacked. That's obviously terabytes of data.

My question is, how can we secure website user information from hackers? Yahoo uses top level security, yet hackers managed to hack them. They are obviously using hashes and several encryption methods, but how did hackers breach their systems?

Are we all at risk?

Are the current security solutions not enough to prevent an attack?
Need answers from penetration testers and security professionals.

Being big does not equal being better secured

Don't assume that becuase they are big and famous, everything they do is better than what you can do.

Nothing has changed - you can secure your small websites the same way you did before, perhaps better since you can learn from Yahoo's mistakes. Continually updating your password hashing, instead of using md5, would be a good start.

Sometimes, being big also means it takes a long time to update security measures, it wouldn't surprise me if "update password hashes" has been in somebodies to-do list for many years.


truecrypt volume - Recover 18char known password with hashcat (characters variations) I have an old truecrypt file that I'd like to decrypt.
I know the 18 characters password I was using at the time, I'm sure of it. However I made a "variation" of it : I mapped some characters to l33t equivalent (I know, I know... I was young !).

I wanted to use hashcat to decrypt it, but I'm confused on how to start from the password and generate variations.

In particular, how do I attempt l33t variations for a single char in the password ? For example, U is |_| so 1 char is mapped to 3 char.

I've been reading about masks and such but it's a bit confusing for me. Where should I start ?

Thank you !

There's currently no hashcat-native way to process a list of rules that perform both one-to-one and one-to-multiple character substitutions to attack TrueCrypt at efficient speeds. Because TrueCrypt is a pretty slow hash, you might be better off performing the substitutions using an external program, and then piping the results to hashcat. (In other words, the overhead of generating candidate passwords yourself won't bottleneck the cracking process.)

Your other options using hashcat directly are as follows. They all have trade-offs.

To replace single characters with other single characters, you can use hashcat's built-in rules system - either by making your own rules, or using one of the "leetspeak" rulesets in the "rules/" directory that is distributed with hashcat. To craft some custom rules, you can study the rules system and those rulesets to get the idea.

The attack would look something like:

hashcat -a 0 -m [62xx] -r rules/leetspeak.rule target.hashfile

Replacing a single character with multiple characters -- your 'U' -> '|_|' case -- is a little trickier.

For general purposes, there are options:

Mapping single characters to multiple characters is supported in what is now called hashcat-legacy (CPU only), using what is called a table attack. However, hashcat-legacy does not support Truecrypt hashes, so that won't work for you.
A similar attack is possible in modern hashcat using the -j and -k parameters and what are called positional parameters in the rules system. Basically, you're telling hashcat to "remember" the position that it found a character, removing the character at that position, and then inserting the characters that you want.

The second approach is a special case of selective character substitution, as documented on the hashcat wiki. Here's the relevant part of that documentation, with the multi-character approach mentioned last:

If you only want to operate on the first instance of a character, you can use %1s, or simply use '/':

$ echo -n 'Odessa77' | hashcat --stdout -j '%1s Dp ip$'
Ode$sa77
$ echo -n 'Odessa77' | hashcat --stdout -j '/s Dp ip$'
Ode$sa77

If you only want to operate on the second instance:

$ echo -n 'Odessa77' | hashcat --stdout -j '%2s Dp ip$'
Odes$a77

… etc. Unlike the 's' rule, which replaces all instances of a character, this allows selection of which instance of a character to replace.

You can also use this functionality to replace one character with multiple characters:

$ echo -n 'p@ssW0rd' | hashcat --stdout -j '%1W DpM ip/ ip\ ip/ ip\'
p@ss\/\/0rd

Notice that the insertion is one character at a time relative to the remembered position, so the characters being inserted are listed in reverse order in the command.

Here's an example closer to your use case:

$ echo TrueCrypt | hashcat --stdout -j '%1u ip| ip_ ip|'
Tr|_|ueCrypt

The major drawback of this approach is that positional parameters only work with -j and -k, and so can only be used one at a time (for a single substitution, not part of a large list of substitutions as you are likely to want).

So that's the long story of why rolling your own character substitution method -- with, say, Python, perl, or even sed -- would be the most flexible solution (and because TrueCrypt is such a "slow" hash, generating the strings at super-high speeds isn't necessary).


Potential employer wants me to email my SSN with an application form, is this a major security risk? I'm job hunting at the moment and I've come across several potential employers that have PDF's that you would download, fill in, and then email to them. I feel EXTREMELY uncomfortable sending my personal information such as name, address, phone number, work history...etc through such insecure methods, never mind my SSN or similar sensitive information.

I feel like this is a major personal security risk for myself. Is it? If so, how can I make that clear to them while still maintaining my eligibility for employment?

I feel like this is a major personal security risk for myself. Is it?

It may be. You may not be targeted specifically, but "email is a private as a postcard". (Not enough reputation for a link, but it's googleable.)

  If so, how can I make that clear to them while still maintaining my eligibility for employment?

I would've called my contact person and explained that I'm a security conscious person and that I don't feel comfortable with sending all that information over the Internet. I would then ask if there is another way for them to recieve it, or if they could wait until an in-person interview.

It may also be illegal for them to require you to send it over unecrypted email, depending on which state you are in. I'm neither a US citizen or a lawyer, but this came to mind:

See http://consumersunion.org/news/state-laws-restricting-private-use-of-social-security-numbers/ and for example California civil code

  1798.85.  (a) Except as provided in this section, a person or entity
  may not do any of the following:
  [...]
     (3) Require an individual to transmit his or her social security
  number over the Internet, unless the connection is secure or the
  social security number is encrypted.


What are the security risks when using free Content delivery networks (CDNs)? I was doing some research on Content Delivery Networks. For those who don't know, a CDN is a large collection of servers that cache and quickly serve up static content such as images, css, js, etc, to end users. CDNs can significantly increase performance by not only caching content but by also limiting the number of network hops to retrieve content.

I'm considering using free CDNs but I was surprised to find next to zero articles, blogs, or forums concerning potential security risks when using them. What are the risks of using free CDNs? How are those risk mitigated?

Since you are usually loading CSS, JavaScript and graphics from a CDN anyone with root-like permissions on the CDN servers (i.e. the company running the CDN) can:

replace your images with other ones, such as porn or other things you don't want your users to see on your website
replace your CSS to load said images, mess up the design, etc. - for IE and Mozilla/Firefox users the CSS could also cause arbitrary JavaScript code to be executed
replace your JavaScript to annoy your user, redirect to other sites, possibly load exploit code to infect them with trojans
(have technical problems causing your site's assets to load much slower than normally)

So all in all, only use a CDN you trust enough not to do those things.


How do I defend against known php hacks I have IPs attempting to probe our web server trying to find open URLs. The two known methods are attempting to find specific nodes on our drupal site, or attempting the ../../../../ trick to try and access the root of the web server.

Both tricks don't do anything against us, but LogWatch sometimes returns that the probing may have been successful returning a 200 HTTP request.

Is there any measures I should be taking to counter this?

The simple answer is that if somebody is doing obvious probing, drop them. phpMyAdmin, for example, is a tell-tale that is never legitimately requested unless you installed it for your own private use. I suggest a 15 minute "drop all packets" response, or ICMP unreachable by admin response if you feel particularly verbose. You can trigger this with Apache rewrite rules, security modules, fail2ban and regular logs, or an application firewall system.

I personally use type 3, code 13 for misbehaving NTP clients (just the application, not taking out the whole host), 9 for killing them at the network, and 10 if the system in question only has 1 IP. Not many folks pay attention to those, but I consider them my "Bad Internet Citizen" flags.


Why isn't free software signed with self-signed certificates? A majority of free software (in particular, Linux ports for Windows) are not signed.

As I understand it, it is quite easy to create a self-signed CA, and sign the software. Distribution would be handled by major free software players, like KDE, Gnome, or whoever is behind the software.

Why isn't this standard practice?

Errata:

This question specifically concerns the practice of porting software from Linux to Windows operating system, and the resulting (perceived) reduction in binary distribution security trust. More specifically, it addresses the practice of distributing binary versions of ported software and the resulting lack of "non-repudiation" as it pertains to digital security.

To rephrase the question, if binary distributions are offered for one platform, and the package source trust infrastructure is implemented, why is such infrastructure not applied to binary "ports".

Signing with a self signed certificate provides no value for the usual windows user.
The signature is invalid from the point of Windows.
The name of the signer is not shown in the elevation prompt. People who would be able to verify such a signature are equally able to verify e.g. a GPG signature which is more common in the open source community.

Signing with a certificate that is seen as valid in windows makes sense. The name of the developer is shown in the elevation prompt, at least. But this certificates cost money, even if there are cheap options for open source developers.

Additional to the cost, certificates (not self signed) need to contain the name of the certificate owner. Some people wouldn't want this publicity. Also, this could be seen as accepting some liability for faults in the software, which also many people providing open source without profit don't want!


Please recommend best-practices documents for sharing encrypted data with non-technical end-users Is there one, or several, "best practices" documents which cover in clear simple language how to share data among a non-technical support staff and non-technical end-users at various organizations?

Our situation:  we have some technical staff well versed in crypto, PKI, key use, and key management.  And nontechnical staff who aren't.

We have mandates / requests to exchange encrypted data with end users.  On the receipt side, we offer a public PGP key and can decrypt data locally in a secure environment.  We encourage (but don't require) users to encrypt data sent to us.

This question arises on the sending side. Clients and regulatory environments vary (finance, energy, healthcare, services, government), as do end-user platforms (mostly PC, some Mac, some other).

I'm leaning toward two suggestions:

Client creates, as needed, a PGP keypair, and shares the public key with us. We encrypt data against that, send it by appropriate means, and they decrypt the data.
We use an appropriate, acceptable symmetric-key encryption tool (e.g.: WinZIP files) and share the password out-of-band.

Not having to generate all the relevant text would be a bonus.

What I've found are references which aren't particularly relevant because:

They're very dated (1990s / early 2000s), technical PGP/GPG references.
They're newer, but generally Linux/Ubuntu-specific references (use 'em, like 'em, but most of our users are elsewhere).
They don't address the business-needs case, or importance of key management for PKI in language an end-user is likely to understand.

Edit: Misread your question. My original solution was how they can provide to you encrypted, you want how you can send them an encrypted file...

I would still say SFTP is an option; once its on their end, it should be their responsibility to secure it. If you server is secured, the ounous is on them once they get the file or they should be specifying what works for them. At the same time, if you made something really convenient that they could use you might be able to get one solution on your side.

You might try the PGP desktop suite which can create secure files and zips. If you really care about security, you won't use basic winzip passwords - you would still need to use key-pairs or exchange a symetics key. I would also recommend trying out truecrypt. You can do that with a password or with keypair. Since TrueCrypt can be run in "traveler" mode with out installation, you can preload it with the private keys they would need to open your files and send them your pre-loaded version (open source so its all good). They would just then need to mount the true crypt archive you sent them and they work with it just like its a disk. You could probably also setup a script on their end so they just drag a truecrypt container onto the batch file and it mounts it for them automatically with the keypair.

There might also be some self extracting encryption/packers out there where they just run the executable. Ultimately though, you can't control policy on a external entities systems and they  will probably copy the files off elsewhere and it should be their responsibility to keep it secured once received (unless you have different contractual requirements).

Leaving original response for other who may pass by one day:

One thing you might try is SFTP. I am not sure if you need encryption at rest, but you can handle that using a script as files come in or have the server store files in a encrypted disk. You provide the end users with WinSCP (I assume anyone working on Linux is technical enough to do what you want), distribute the key, give them a username and password. You could probably write a one page document as well. This is the solution I usually recommend and have recommend to a client in the past who had to obtain lots of data files from their clients.

I find many organization use regular FTP, so SFTP seems similar; winscp or any even Filezilla are similar to a file system and have drag and drop. Each user can have a drop folder, etc; you can force key changes and password changes on an interval. The software on the user end is free.

You could also try to get them to buy or foot the bill for something like PGP desktop tools and have them make containers and email them to you...but they will probably still have the file unencrypted on their end so its not any real protection on the client end. You can manage security how you want once you receive the file.


is this a good practice for storing private keys? I'm working on a centralized exchange for cryptocurrencies. the approach that I'm taking for some reasons is to create an account(private key) per user inside platform. so these accounts should be controlled by platform. now my problem is how to safely store private keys in server and then safely retrieve them for signing transactions. since I'm using a VPS, it's not possible to use HSM or any other hardware-based solutions.
the approach I'm thinking about for securing private keys is this: for each user when he creates his account, app will generate a private key and encrypt that private key using his password. now if a user wants to transfer cryptocurrency from his inside platform account to his external account, in addition to his external account address, he also have to provide his password and app uses that password to decrypt his internal account's private key and sign the transaction using it.
so even if my database compromises, the attacker cant use private keys since they are encrypted and he cant use password to decrypt them since passwords are hashed.
now I wanna know that is there any problem with this approach that I dont see?

edit- also I'm gonna keep an offline backup of private keys in which passwords are not encrypted. so forget password option gonna be a bit manual. anytime a user forget his password, an admin will find user's private key in backup file and generate a new password and update the database using this new password and user's private key and after that email password to user.

thanks in advance.

Don't try to learn data security by building a crypto exchange. It's like learning how to make a boat by creating a cruise ship. Or learn Physics starting with Quantum Chromodynamics.
Try a secure file storage first. Or a secure messaging platform. Or a secure emoji election. Simpler things, no financial damage if done wrong, no massive lawsuits, no need to flee from your country.
In a crypto exchange, the users don't have private keys, they have passwords for their accounts, like an email, or bank account. Think of a bank: the users usually don't have a private safe inside the bank, only the bank have one. Users have their funds stored on the bank database, and the bank is the owner of all the money. Regulations aside, the bank is the real owner of the money.
When users want to transfer their funds to another wallet, you is the one making the transfer in your own name. You can have a wallet for every user, but you are the owner of the wallet. Users will either don't care about the private keys (the vast majority of users), or will never ever trust you their private keys. There won't be much users not on those groups: ones savvy enough to have their own private keys in hand and willing to give you access to their key.
Crypto stored on your exchange will not be on a hot wallet, but a cold one. The hot, online wallet will only cover the day to day withdraws, and all the funds should stay offline. In the case of a wallet theft, you don't lose everything.
You don't want to have only one cold storage either. Losing access to it would lose access to all the funds, and that will be catastrophic. You will rather have several cold wallets, and keep them balanced. And the private keys should be stored in a way that in the even of the death of the owner, someone could access the funds. This is usually called Break Glass Procedure, and it's a safeguard against losing access forever in case of a disaster.
It should be tested before a disaster, and be implemented in a way that's not possible to use the emergency passwords undetected, and require more than one user. It could involve, for example, the Shamir's Secret Sharing scheme for half of the private key, and a printout stored on a tamper-evident container stored on a bank safe with an access ledger (or the owner will, safe with his attorney). In the case of disaster, a couple of high rank employees would get together to have half the key, and get the other half on storage.
Backing up private keys are usually a bad idea. They are the only protection against the total loss of funds, so the backup would have to be protected as much as the private key itself. And you will not want to use a VPS for hosting a crypto exchange. You will either have your own datacenter, or at minimum a co-location of your own custom server chassis with tamper proof sensors and automated data destruction in case of tampering.


Why use one URL for all "pages" on my site? I have heard that I should (A) use one URL for all "pages" on my site, such that what page is shown is determined by the session state, and (B) don't use an extension like .php. One curious fellow even claimed  (C) in a talk that people should not return 200 codes but should use randomly chosen codes.

I guess I understand B and C as these confuse would-be attackers who are running Nikto or Skipfish or whatever.

What are the reasons for doing the solo endpoint? It could be a lot of work to convert my PHP4 code to use only one endpoint since I have maybe 40 PHP files. I would've thought that attackers would have more trouble dealing with many URLs, one per PHP file.

If these were propositions made in the context of information security, then they all would be examples of security through obscurity. From the Wikipedia article linked:

In security engineering, security through obscurity is the use of secrecy of design or implementation to provide security. Security through obscurity is discouraged and not recommended by standards bodies. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that if the flaws are not known, then attackers will be unlikely to find them. A system may use security through obscurity as a defense in depth measure; while all known security vulnerabilities would be mitigated through other measures, public disclosure of products and versions in use makes them early targets for newly discovered vulnerabilities in those products and versions. An attacker's first step is usually information gathering; this step is delayed by security through obscurity. The technique stands in contrast with security by design and open security, although many real-world projects include elements of all strategies.
Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of simplicity. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."

Generally speaking, it is a very poor approach to reasoning about a system's security. I do not see any security benefits that might be yielded by employing just one single endpoint, nor would omitting file extensions enhance the security of your web service. There may or may not exist benefits of omission in the realm of search engine optimization (SEO), and I think that may have been what was meant originally. I see even less SEO benefits for the one-page website, however, as pointed out by @Fiasco Labs. I don't market myself as an SEO guru (consult your local Digital Point forums).
The idea of using just a single endpoint may have spawned from today's increasingly common practice of delegating logic and routing to the client side while only serving out one page with static dependencies, and otherwise just performing session-authenticated database/long-term state operations in response to user interaction (see Meteor). Might the recommendation of omitting ".php" also have just been spawned from one person's distaste for that language in particular? I was not there.


How can data URLs be exploited? I found I can upload an avatar using data URL (the one you get by googling some picture and right-clicking on its miniature) by just changing type="file" to type="url". Initially user shouldn't be able to perfom this action. The data URL looks like this: data:image/jpeg;base64,/9j/[lots of random letters and digits] How can this vulnerability be exploited?
Thank you in advance!

Data URI is a standard for embedding the data you want to use directly within your page (that is - not be in need to use an external file). This is handled by the browser and is essentially a Base64 version of the binary file (a picture in your case).

So, client wise, you are as safe as your browser is.

I did not fully understand your question but you are asking whether such an encoding schema can be used to push malicious payload to a server - probably yes. It all depends on how whatever is received by the web application is later processed. There is nothing like a "generic exploit" in that case and the Base64 data you send are not special per se.


Fuzzing a mips interactive binary I need to fuzz an interactive binary (for which I do not have the source code) compiled for a MIPS architecture. It is a login console and i'd like to fuzz the interactive text provided by the user (ie.: the console asks for a username, the user types it in, the console asks for a password, the users provides it. I want to fuzz username and password).
Is there any tool that helps me doing that? Furthermore, the tool should be able to fuzz via qemu or something similar since I am not using a MIPS machine to do so.

AFL can perform qemu user-mode fuzzing.  It is capable of providing the input to the executable on standard in, so it can handle most interactive programs.  However, if your login binary is using special ioctls to directly access the terminal, you may still need to do some work to begin fuzzing it.  In that case, I'd suggest building an LD_PRELOAD shim to transform the terminal-specific ioctls into raw read operations from stdin.


Is my private SSH key compromised if someone hacks my Wi-Fi? I'm new to this and trying to understand, so bear with me.

I set up a droplet on Digital Ocean and configured SSH keys per Digital Ocean's tutorial. This required running ssh-keygen -t rsa on my laptop and then providing my Digital Ocean droplet with the public key.

My understanding is that these private and public keys were generated on my laptop; in other words, if my laptop were damaged/stolen, my private key would be gone forever (don't worry, I have a backup that I printed out and stored away safely). However, my question is this: is this private key accessible to someone who is able to access my Wi-Fi network?

Getting your private key would require that someone has the ability to read data off of your computer. If they're on your wifi it makes it significantly more likely that they can get this information but it still requires that there is some sort of vulnerability that allows them to get at the data on your harddisk (assuming you don't just start sending your private key over the network for any reason).

Common problems might be having a share on your computer you might've forgotten about or unpatched software + bad firewall configuration that would allow them to perform some sort of read operation via a previously known vulnerability (think: old IIS and directory traversal).

Another attack vector to look at is if they are on your network, they have the ability to influence the traffic going to your machine. DNS Spoofing a website on your local network and then tricking you into downloading some sort of malicious application would be another route they could take.

Tl;dr: Just because they're on your network does not explicitly mean they can read the private key but it opens up a lot of different attack vectors that may not have been possible before making it more likely that they could get to your private key.


How to tell if a webapp transmits my password in cleartext? I am trying to see if a webapp transmit password in some form of cleartext. The problem is that the web app is NOT using https! This is why I wondering is my passwords is sent in clear text.

I've found a cookie in my browser containing the following :

usr=waytodoor&mdp=3C5115ECB18725EBFFF4BB11F9D17798358477D6E11E0188D54BAB80C86D38D41A16F76D8D0B253445774484FB1AE22E9FC13E257CFB9E7B7466F1BA5417EA004FCBB4E7965CA571819146A148EED15A2AEA6E47D9DF338B534264FBC99A57952212629BA79BB34BE9C8C60B73F1F681EE872C64

From what I can tell, usr is my user name, and mdp ("mot de passe" in french means password).

So, is the mdp field of the cookie my password (and, if it's the case, how could I "decrypt" it ?), or just some kind of token?
The password is 7 chars long.

I tried to convert it from hex or from base 64, but no luck.

EDIT: Included statement that HTTPS is not being used.

EDIT2 : The website is a webstite for students. Passwords are given by the school at the beginning of the year. We can't change them.

I suspect that some students are ARP'ing the school network. I try to disconnect as fast as possible from the website to invalidate the cookies, but I wanted to know if they can find the password from the cookie.

There are two reasons to ask if your password is being encrypted:

You are worried about the security of the site.
You are worried about the security of your password.

Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just use the site with care.

Regarding the security of your password, without SSL, it doesn't really matter. Someone can steal your session cookie and pretend to be you without knowing your password. So be sure not to reuse the password on other sites (or reuse any password ever) to prevent a password exposure on this site from compromising your accounts on other sites.

Edit In response to your concern about ARP spoofing, without SSL, it may be possible that they establish a MiTM. Once they do that, they can see the cookie. Without deeper inspection of the web site, I cannot tell you if the cookie leaks your password. Perhaps it is securely encrypted, perhaps not. That said, once they have an MiTM, they can alter the JavaScript that is sent to your browser. This would allow them to alter what is sent on the wire, thereby getting your password. And, while I can't be certain without further examination, that cookie is looking to me like a pass the hash vulnerability. If that is the case, then there is no need for them to steal your password as the cookie's value is as good as a password. All of this boils down to, without SSL,there is no security.


Is sending plaintext passwords to a SQL Server database a security risk? I have a database which has stored procedures which take plaintext passwords. It hashes them and inserts them into the DB.

If an attacker has access to the DB connection, it is possible to intercept calls to the DB using SQL Server Profiler and see the passed in plaintext passwords. I understand that SSL will encrypt network traffic to the DB, but it won't stop an attacker sniffing the stored procedure parameters.

Is there a security risk in having these passwords sent through unencrypted?

SQL Server has the option to encrypt the connection between application and database. When you operate SQL server in an untrusted environment, it is recommended that you enable it. When you do, hashing the passwords before sending them to the database is unnecessary as long as you trust your DB administrator.

Additionally, most deployments of SQL server will have an application server in a DMZ and the SQL server on the LAN, which means you operate in a trusted environment. Unless you have a very high security standard, having no encryption wouldn't be a big security risk.


What security standards and regulations are in place for bank ATM? Are there any international or US mandated standards and regulations that apply to communications between automatic teller machines and bank's central office? Are banks or ATM operators subjected to periodic audits that include ATM security controls?  Who/what guarantees that the communications between the bank and ATM cannot be faked or tapped for malicious exploitation?

MasterCard and VISA enforce very strict regulations on any system which operates in any way in the vicinity of their precious credit cards. If a bank or an ATM operator lets the communication be tapped, then the VISA thugs will skin them alive, trample their organs, then expose their dismembered bodies on the Wall Street Bull, as a warning for other banks. Their fierceness is much higher than what any public administration could ever hope to achieve; because this is about important stuff (money). This is private business, with contracts; the legislator did not meddle with this beyond asserting that customers are not ultimately responsible unless proven otherwise (thus forcing banks to take their responsibilities).


Are Chrome extensions like Advanced REST Client safe to use? I'm just getting into learning REST and came across this great application that instantly lets me test out requests (Advanced Rest Client).  The question arose that since it is an extension to the browser and I had to log my credentials in to run the request, is it safe to use?  I see nothing but great reviews for this extension and it has 350,000+ downloads so I would assume it's safe.  Assuming doesn't get me anywhere though.

I worked this summer around 3 browsers: Firefox, Google Chrome and Internet Explorer: by principle any extension is a source of vulnerability if not an exploit in itself. Trust me it is not the number of people who use REST that will make you comfortable to use it because there had been several and more popular extensions that were discovered finally later to be too dangerous. You can find examples of such malicious extensions (even if most of them were used as spywares and adwares) on here and there, for example.


What happens if I change RR on my domain's DNS after DNSSEC has already been enabled? DNSSEC security starts by first grouping DNS records (RR) of the same type into a record set (RRset) and then this RRset gets signed...
Does this mean that I have to completely define all the RR in my DNS prior to enabling DNSSEC? What would happen if I added some DANE TLSA records after DANE was already enabled?

What you suggest would be rather silly, wouldn't it? It would mean that you would have to disable DNSSEC every time you make any modification to your zone, which would both be very laborious and leave your zone unprotected for a long time (for the TTL on the parent zone).
When you enable DNSSEC, the parent zone adds DS records authorizing your DNSKEY to sign the records in your zone. When you change a RRset you simply sign it again with your key, resulting in a new RRSIG.
Furthermore, RRSIG records have Signature Validity Periods (RFC 6781, 4.4.2); you must resign the RRset before it expires. It's better automate this! Also, until the validity period expires, it would be possible to use the old RRSIG to sign an old RRset and perform a replay attack. It's all explained in detail in the RFC.


Vigenere Cipher - help with decryption (by hand) So this is a Vigenere cipher-text

EORLL TQFDI HOEZF CHBQN IFGGQ MBVXM SIMGK NCCSV
WSXYD VTLQS BVBMJ YRTXO JCNXH THWOD FTDCC RMHEH
SNXVY FLSXT ICNXM GUMET HMTUR PENSU TZHMV LODGN
MINKA DTLOG HEVNI DXQUG AZGRM YDEXR TUYRM LYXNZ
ZGJ

The index of coincidence gave a shift of six (6): I know this is right (I used an online Java applet to decrypt the whole thing using the key 'QUARTZ').

However, in this question we are only told the first and last two letters of the Key - 'Q' and 'TZ.'

So far I have split the ciphertext into slices using this awesome applet. So the first slice is 0, k, 2k, 3k, 4k; the second is 1, k + 1, 2k + 1, 3k + 1; et cetera.

KeyPos=0: EQEQQSCXQJJHDEYIUTSVMTVUMTYJ
KeyPos=1: OFZNMICYSYCWCHFCMUULILNGYUX
KeyPos=2: RDFIBMSDBRNOCSLNERTONOIADYN
KeyPos=3: LICFVGVVVTXDRNSXTPZDKGDZERZ
KeyPos=4: LHHGXKWTBXHFMXXMHEHGAHXGXMZ
KeyPos=5: TOBGMNSLMOTTHVTGMNMNDEQRRLG

My idea was to calculate the highest-frequency letter in each block, hoping that the most frequent letter would give me some clue as to how to find 'U,' 'A' and 'R.' However, the most frequent letters in these blocks are:

KeyPos=0: Q,4 T,3 E,3, J,3
KeyPos=1: C,4 U,3 Y,3
KeyPos=2: N,4 O,3 R,3 D,3 B,2
KeyPos=3: V,4 D,3 Z,3
KeyPos=4: H,6 X,6 M,3 G,3
KeyPos=5: M,4 T,4 N,3 G,3

Which yields QCNVHM, or QUNVHM (being generous), neither of which are that close to QUARTZ. There are online applets that can crack this no problem, so it mustn't be too short a text to yield decent frequency counts from the blocks.

I guess I must be approaching this the wrong way. I just hoped one of you might be able to offer some clue as to where I am going wrong.

Thanks for any help!

You are approaching this the wrong way. What you have here is the ciphertext. This means that the most frequent letter in each block will (or should) correspond to the most frequent letter in the cleartext. With a long enough text, you can assume that this is the letter 'E'. The most frequent letter in each position is not the letter of the keyword.

This means that you can find each letter of the key using the most frequent letter at a position and its offset from the letter 'E'. Knowing that the letter 'A' will give you a offset of 0, and the letter 'Z' will give you a offset of 25, it is trivial to guess the original key.

However, this only works for longer texts, since the letter distribution is easy enough to mess up in shorter ones. Using the cleartext from your question, the most frequent letter is, in fact, 'O', not 'E'. In addition, because the text is so short, the letter frequencies at each of the positions of the key are even more skewed.

I am not sure how you managed to decode this automatically. The only way I can think of would be to check for dictionary words in both the key and the resulting output, ignoring any keys which do not make sense.

In general, the Vigenere cipher can be cracked easily for longer texts with shorter keys. If you have a short text (like here), or a longer key, then it gets harder. Ideally, you would use a random key that is longer than the plaintext, so it never repeats, which guarantees that the ciphertext cannot be decoded without the key.


Credit Card Tokenization and multiple parties Business B accepts the credit card information under SAQ-A-EP guidelines and gets the token T back from the payment services provider P. The token now needs to be sent (by B) to partners P1 or P2 or P3. for them to charge the customers of B, for services provided by the partners.

Is this a viable scenario? In other words can a business just forward the token and have the partner add transaction information for processing?  If not, how does the business that essentially acts as an intermediary process payment through partners?

Is this a viable scenario? In other words can a business just forward
  the token and have the partner add transaction information for
  processing?

Generally, no - not because DSS prohibits sharing of a token, but because the token is only useful in the context of the relationship between the processor and the merchant.  Random parties P1 - P3 cannot present the token to the processor and have the processor do anything with it; they must themselves have a business relationship with that processor.  And the tokens provided by a processor to one merchant may not be portable to other merchants using the same provider.

  If not, how does the business that essentially acts as an intermediary
  process payment through partners?

It sounds like you're looking for something like the Payment Facilitator, or PayFac*, model.  It allows merchant B to act as a middleman between P1/P2/P3 (who are "sub-merchants" in this model) and processor P.  The PayFac B will generally work to provide interfaces for sub-merchants to route their payment flow through processor P under the auspices of B, and then will take the aggregated monetary distribution from P and distribute the correct breakdown to P1/P2/P3.  The Card data and the tokens will stay with B; customers of P1/P2/P3 will flow through B for future transactions (usually without it being obvious that they're doing so).

"Payment Gateway" is one of the terms you might hear used to describe Payment Facilitators, although I will caution that "Payment Gateway" as a phrase also includes a lot of different non-PayFac setups and means different things to different people.

Essentially, P1/P2/P3 are handing over the complexity of dealing with the cards to the PayFac, B.  But they have the benefit of enabling their business by accepting cards.

*PayFac is the Vantiv term for this sort of setup; I don't know if there's a generic term or what the names of competing offerings are.  Full disclosure, I am a Vantiv employee.  Limiting the example to Vantiv is a sign of my ignorance rather than bias per se :).  If anyone names competing equivalents in the comments, I'm happy to bubble them up into the answer itself.


TLS 1.0 and TLS 1.2 enable simultaneously We have a web front end server with TLS 1.0 enabled for web application in IIS.

This WFE communicates internally with external workflow manager server through fqdn and TLS 1.0

If we enable TLS 1.2 in WFE server, will the communication break between WFE and external workflow manager?

Can we have simultaneous support for TLS 1.0 and TLS 1.2?

Yes, you can have simultaneous support for TLS 1.0 and TLS 1.2.

Which one will actually be used will depends on the other end too.

Configuring 1.2 everywhere will make it work with 1.2 but you can also let 1.0 be on just in case you missed a device that still uses 1.0.


Security Considerations To Account for When Redirecting From Microservice to Another I am evaluating the above service design where I want to have mechanism to pass a user through multiple microservices. In this simple example, the user goes through a sign-up process and once done, the user is redirected to another microservice (B).

The session-id for microservice A is stored in a session store. However, when the user is redirected to microservice B then a new session-id is generated by microservice B and so this is stored as well in the session store.

This allows the user to traverse back and forth between microservices. Are there any security implications with this design?

The biggest possible security implication I can see with the details presented is that you might accidentally DoS your visitors if every individual service has its own session, and therefore session cookie. Once you hit the cookie limit (typically 4096 bytes), browsers will start ignoring cookies, possibly arbitrary ones, and that will cause sessions to start being dropped.

Another possible vulnerability is that if you have to examine multiple sessions in order to do work, it's possible that a malicious user might send a large number of different session ids, real or otherwise, and force your services to examine each one, which at best would cost CPU cycles (and thus money), and at worst cause a wider system DoS.

Both of these would be mitigated by only having a single session for the user.


What to do when a conference uses HTTP and stores passwords in plaintext? So, a site that I was using to sign up for an academic conference transmits information unencrypted (HTTP), including passwords. Then I see, using the 'forgot password' function gets me an email with my password in plaintext. I understand the security implications of this - this is horrible.

My questions is, what should I do? Should I send them an email, and if so, how should I convey this information? Should I tell/warn colleagues about this?

Make sure they aren't part of the network of predatory publishers
(such as W.A.S.E.T or O.M.I.C.S).
You should email the conference organizer to alert them to these issues. If there is a national organization behind it consider checking to see if the issue is endemic and if so alert the national governing body of that organization as well.

Note* be prepared for them to not be thankful for your help.


When downloading from an https web page - will the download also use ssl? If I click on a download link on a page that uses ssl, will the download also use ssl?

If the answer is not (or: sometimes yes, sometimes not) - is there any way I can force it to be protected?

I'm asking this because downloading a program, and having it being tampered on the way can be just as bad, if not worse, than having a web page or my request of it, tampered or intercepted.

When you "download from a page", this means that you are actually following a link. Somewhere in the HTML source for the page is the link which states where the file actually is.

The download will use HTTPS if the link says so; it will use HTTP if the link says so. That the page itself was obtained with SSL is quite orthogonal: a page obtained over SSL may contain a non-SSL link, and vice-versa. If the link is a "basic link" then letting your mouse cursor "hover" over the link allows your browser to display somewhere in a status bar (traditionally at the bottom of the window) what URL it will actually use when you click; that way, you can see whether the download will use SSL or not.

(If the link in the HTML page is relative -- it does not specify a server name or protocol, and points to a file on the same server -- then the same protocol as the one used to obtain the HTML page will be used. However, a "full link" can also be specified, and will include an explicit protocol, which will be https:// or http://, for, respectively, SSL and not-SSL.)

Edit: an example of "hovering":

When I bring my mouse over the "Windows Installer (64-bit)" link, the browser displays at the bottom the link which will be followed for this download. That URL begins with https://, so that download will use SSL.

(Browser here is Chromium on Linux; details of such link displaying depend on OS and browser.)

Some software packages may benefit from additional protection. For instance, installer packages for Windows can be signed; the signature gives you some strong guarantee against modification of data in transit, regardless of how you obtained the file. Another traditional method is with hash values: an SSL powered Web site lists the hashes of the files (with some hash function like MD5); you can recompute the hash on what you downloaded and see if it matches the values on the Web site (see this page for an example, in the case of the ISO images for installation CD/DVD for the Ubuntu operating system).

These methods allow for decoupling the transfer method from the verification. That way, you can get the files from efficient mediums (e.g. some peer-to-peer protocol) and yet verify that you obtained the genuine thing.


Would it be a security risk if I moved PsTools to the windows system32 folder? Microsfot Sysinternals has a helper program called PsTools inside this PsTools suite are a bunch of .exe tools that I use regularly from a command line.

I was thinking about moving all these files to my system32 directory so they would be available on my prompt path. Is this a bad idea?

I use them from \Windows\ for easy quick deployment.

No problem whatsoever from a security perspective.

I try not to use the system directories, as things are hard to trace in there already, but directly in \Windows\ things are very clear and easy to follow from a "what exe files should be there" perspective.


Creating Secure PHP Sessions I have already created and refined both registration and login systems, However I am lead to believe the tricky part comes when you are creating a session. As far as I know this is due to both Hijacking and fixation. Which in all honesty I don't fully understand the concept of.

I have browsed the internet all day and done a large amount of research. he following articles have been useful to me so far:

How to Create Bulletproof Sessions

PHP Security Guide: Sessions

So far I have very little, I could really use some help and guidance. This is some of what I have got so far:

When a users password is matched and they have confirmed their identity using the login script the following function is called. The session is started at the top of the login script.

function begin_session()
{
session_regenerate_id();
$_SESSION['valid'] = 1;
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
}

I am using the $_SESSION['valid'] variable as a simple the user is logged in confirmation. I am assigning the session to a single User Agent and IP Address. I see how the User Agent is fairly useless as it can be easily forged but I feel it's better to have it rather than not have it.

It's apparent to me users with changing/dynamic ip's would be logged out... but everyone who has told me this has failed to present me with a better option, or explain it to me better.

I am then using the following function to match the current user agent to the original user agent logged at the creation of the session.

    function authenticate()
{
session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR'])) {
    session_destroy();
echo 'die';
    header('Location: http://website login page/');
    exit();
}
}

At the moment due to my lack of understanding, I don't know where I am vulnerable from and or where I can go and make improvements. This is all very new to me and at the moment at least I am trying to learn this in my spare time. It's all new to me, and I want to ensure the best work.

First and foremost,  STOP USING MD5!  It is a broken hash function,  and its been broken for many years.  Also you have to use an hmac,  calling md5 directly is vulnerable to a length extension attack.

Testing the ip address is problematic because this value can change if the user is behind a load balancer,  which is commonly used by universes and corporate offices.

The attacker will always have the user-agent, and this value is very easy to brute force.    Testing this value is in no way shape or form a "security measure".  Its a lot like having a variable is_attacker=no and making sure this value is "no",  which is A JOKE!  When I see a programmer doing this I smell blood,  if they actually think this helps improve security then they have likely made other mistakes.

Set your php session configurations as follows:

session.cookie_httponly = 1 (helps mitigate xss)
session.session.use_only_cookies = 1 (prevents session fixation)
session.entropy_file = "/dev/urandom" (better entropy source)
session.cookie_lifetime = 0  (smaller exploitation window for xss/csrf/clickjacking...)
session.cookie_secure = 1 (owasp a9 violations)


Recommended # of iterations when using PKBDF2-SHA256? I'm curious if anyone has any advice or points of reference when it comes to determining how many iterations is 'good enough' when using PBKDF2 (specifically with SHA-256). Certainly, 'good enough' is subjective and hard to define, varies by application & risk profile, and what's 'good enough' today is likely not 'good enough' tomorrow...

But the question remains, what does the industry currently think 'good enough' is? What reference points are available for comparison?

Some references I've located:

Sept 2000 - 1000+ rounds recommended (source: RFC 2898)
Feb 2005 - AES in Kerberos 5 'defaults' to 4096 rounds of SHA-1. (source: RFC 3962)
Sept 2010 - ElcomSoft claims iOS 3.x uses 2,000 iterations, iOS 4.x uses 10,000 iterations, shows BlackBerry uses 1 (exact hash algorithm is not stated) (source: ElcomSoft)
May 2011 - LastPass uses 100,000 iterations of SHA-256 (source: LastPass)
Jun 2015 - StableBit uses 200,000 iterations of SHA-512 (source: StableBit CloudDrive Nuts & Bolts)
Aug 2015 - CloudBerry uses 1,000 iterations of SHA-1 (source: CloudBerry Lab Security Consideration (pdf))

I'd appreciate any additional references or feedback about how you determined how many iterations was 'good enough' for your application.

As additional background, I'm considering PBKDF2-SHA256 as the method used to hash user passwords for storage for a security conscious web site. My planned PBKDF2 salt is: a per-user random salt (stored in the clear with each user record) XOR'ed with a global salt. The objective is to increase the cost of brute forcing passwords and to avoid revealing pairs of users with identical passwords.

References:

RFC 2898: PKCS #5: Password-Based Cryptography Specification v2.0
RFC 3962: Advanced Encryption Standard (AES) Encryption for Kerberos 5
PBKDF2: Password Based Key Derivation Function v2

You should use the maximum number of rounds which is tolerable, performance-wise, in your application. The number of rounds is a slowdown factor, which you use on the basis that under normal usage conditions, such a slowdown has negligible impact for you (the user will not see it, the extra CPU cost does not imply buying a bigger server, and so on). This heavily depends on the operational context: what machines are involved, how many user authentications per second... so there is no one-size-fits-all response.

The wide picture goes thus:

The time to verify a single password is v on your system. You can adjust this time by selecting the number of rounds in PBKDF2.
A potential attacker can gather f times more CPU power than you (e.g. you have a single server, and the attacker has 100 big PCs, each being twice faster than your server: this leads to f=200).
The average user has a password of entropy n bits (this means that trying to guess a user password, with a dictionary of "plausible passwords", will take on average 2n-1 tries).
The attacker will find your system worth attacking if the average password can be cracked in time less than p (that's the attacker's "patience").

Your goal is to make the average cost to break a single password exceed the attacker's patience, so that he does not even try, and goes on to concentrate on another, easier target. With the notations detailed above, this means that you want:

v·2n-1 > f·p

p is beyond your control; it can be estimated with regards to the value of the data and systems protected by the user passwords. Let's say that p is one month (if it takes more than one month, the attacker will not bother trying). You can make f smaller by buying a bigger server; on the other hand, the attacker will try to make f bigger by buying bigger machines. An aggravating point is that password cracking is an embarrassingly parallel task, so the attacker will get a large boost by using a GPU which supports general programming; so a typical f will still range in the order of a few hundreds.

n relates to the quality of the passwords, which you can somehow influence through a strict password-selection policy, but realistically you will have a hard time getting a value of n beyond, say, 32 bits. If you try to enforce stronger passwords, users will begin to actively fight you, with workarounds such as reusing passwords from elsewhere, writing passwords on sticky notes, and so on.

So the remaining parameter is v. With f = 200 (an attacker with a dozen good GPU), a patience of one month, and n = 32, you need v to be at least 241 milliseconds (note: I initially wrote "8 milliseconds" here, which is wrong -- this is the figure for a patience of one day instead of one month). So you should set the number of rounds in PBKDF2 such that computing it over a single password takes at least that much time on your server. You will still be able to verify four passwords per second with a single core, so the CPU impact is probably negligible(*). Actually, it is safer to use more rounds than that, because, let's face it, getting 32 bits worth of entropy out of the average user password is a bit optimistic; on the other hand, not many attacks will devote dozens of PC for one full month to the task of cracking a single password, so maybe an "attacker's patience" of one day is more realistic, leading to a password verification cost of 8 milliseconds.

So you need to make a few benchmarks. Also, the above works as long as your PBKDF2/SHA-256 implementation is fast. For instance, if you use a fully C#/Java-based implementation, you will get the typical 2 to 3 slowdown factor (compared to C or assembly) for CPU-intensive tasks; in the notations above, this is equivalent to multiplying f by 2 or 3. As a comparison baseline, a 2.4 GHz Core2 CPU can perform about 2.3 millions of elementary SHA-256 computations per second (with a single core), so this would imply, on that CPU, about 20000 rounds to achieve the "8 milliseconds" goal.

(*) Take care that making password verification more expensive also makes your server more vulnerable to Denial-of-Service attacks. You should apply some basic countermeasures, such as temporarily blacklisting client IP addresses that send too many requests per second. You need to do that anyway, to thwart online dictionary attacks.


Can environment variables created for a unix account be viewable by another account? If I run a program that accepts configs from environment variables under non-privileged user userA; can a user with root access read those environment varibles ?

Usually the user root has no problems to see such variables. At least one way to do this is simply using the ps command:

# as non-privileged user
user@system$ foo=bar sleep 500

# as root
root@system# ps axe
... 0:00 sleep 500 foo=bar TERM=xterm ...

Visibility to another non-privileged account instead is usually not given.


Why request and response calls in my burp suite python plugin come in such random order? So I am trying to write this burp plugin using jython and python for burp suite. Now in the processHttpMessage body, I found before a proper execution of the entire method takes place for one request message, it starts executing for another request message. Why is this? And how can I stop it from happening?

Requests are processed asynchronously in Burp, so every time the browser makes a new HTTP request it'll trigger your script. You cannot switch this behaviour off (it's integral to Burp's proxy engine) so your code will need to be thread-safe.


Unusual ownership-ID using localStorage; any possible issues? I'm working on a small side project in PHP. I may yet include some sort of actual username/password registration down the line, but for now, for ease of attracting attention, my goal is to allow for any anonymous user to use my site without registering. Here's how it works, in general:

User goes to the site, and creates a "thing"
In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is.
The "success" page uses Javascript localStorage to store the string generated.
In the future, if the user wishes to make small changes to their "thing", they fill out a form on a page. Then, the request is sent with this localStorage string. On serverside, it is validated against the hash before updating the thing.
Someday when I implement usernames/passwords, users can visit a page to gain ownership of their items by grabbing all their localStorage values.

A few things to think about:

I've been reading up on XSS vulnerabilities used to steal cookie session IDs and similar information. The common trait with a lot of them it seems is that the bad guy is able to run Javascript on the target domain, which seems like a big assumption to me. Needless to say, I don't use eval(), and even try to avoid innerHtml whenever possible. I'm especially aware of any times that user-generated strings are put to use. I think I'm helped by the fact that my site is not especially complex or user-customizable.

I know of the HttpOnly header, but I like Javascript, and I want a lot of my site's actions to be asynchronous (so you can save a form's information without loading a new page)

Also, I should note that the information saved on my site is best labelled as entertainment, and in its proper intent, should not contain sensitive information, even so much as E-mail addresses (those would come when I implement usernames/passwords) so I think I'm fine with someone being able to break in by physical access (ie, stealing a user's laptop); I'm basically trying to find the right balance of security to convenience.

I'm also now considering that, depending on how costly it is to get a certificate, HTTPS would be important enough to include. I guess I would just be surprised at someone watching HTTP packets just to take ownership of someone else's "thing".

Seems to me to be a reasonably secure approach in lieu of having user accounts and session management. HTTPS is a must but I'd also look at the following points to address your specific issues.

  In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is.

Make sure the generated string is generated using a cryptographically secure mechanism. e.g. openssl_random_pseudo_bytes

If you want to add extra security you could add a salt, or better still use bcrypt for the server stored value.

  I know of the HttpOnly header, but I like Javascript, and I want a lot of my site's actions to be asynchronous (so you can save a form's information without loading a new page)

You could use a cookie with HttpOnly set - the cookie will still be sent with your AJAX requests, it will only be the JavaScript itself that won't be able to access it. Also set the secure flag and use this in conjuction with HTTPS to make sure your cookie is only transmitted over a secure connection.

  The common trait with a lot of them it seems is that the bad guy is able to run Javascript on the target domain, which seems like a big assumption to me.

That is in fact the definition of XSS in that an attacker can run JavaScript on the target domain. Make sure you're following the advice in the  XSS (Cross Site Scripting) Prevention Cheat Sheet


What are the changes in PKI when i move from TLS protocol to IPSec Protocol? Currently i am using TLS protocol for a secure communication between my server and client. I use PKI for key/certificate Management. If i want to switch to IPsec for secure communication, how will the PKI be affected or what changes should i do?

TLS is authentication at the application level while IPSec is essentially authentication of a device. In TLS it is common that the client only authenticates the server while in IPSec both peers authenticate each other (i.e. mutual authentication). This means your PKI must now reflects devices and not applications and it needs to reflect both sides of a communication. How this affects your specific existing PKI is unknown.


Is it bad practice to reuse private EC key as a shared secret for a symmetric algorithm? The encrypted text is public, embedded in the binary of my software which is published on the internets. I know the open text but there’s large circle of third parties who might know it too, despite it’s a secret (that’s an access key to a cloud provider).

Am I correct that even if the cloud provider leaks the secret text, an attacker then knows both open text and encrypted text, attacker might be able to use these 2 pieces to reconstruct the symmetric AES key, but even then they can’t reconstruct the private EC key I used as a source of that, because Rfc2898DeriveBytes is a one way thing?

Here's C# code which decrypts:

byte[] privateKeyBytes = // private key bytes, decoded Base64 from PEM file in NAND flash
byte[] deriveSalt = new bytes[ 8 ] {…} // data from random.org
var k = new Rfc2898DeriveBytes( privateKeyBytes, deriveSalt, 77 );
byte[] aesKey = k.GetBytes( 16 );
Aes aes = Aes.Create();
aes.Key = aesKey;
aes.IV = new byte[ 16 ] {…} // data from random.org
// Use Aes to decrypt

Yes, it's bad practice to use a key for two different purposes. This can have obvious or subtle problems.

In this specific case, I don't see an obvious security problem. Rfc2898DeriveBytes implements PBKDF2, which is a key derivation function. Given the output, it's impossible to reconstruct the input except by guessing. Since a private key has enough entropy to be unguessable, it's impossible to find privateKeyBytes from k and deriveSalt.

Nonetheless there are several problems in your mechanism.

Don't use the EC private key as input. If you need to derive everything from a single key due to extremely limited storage, have a single root secret key and derive everything from that, including your EC private key(s). Derive each key with a different salt.
Rfc2898DeriveBytes is not the right kind of function to use here. It's a password-based key derivation function, but you don't have a low-entropy secret such as a password, you have a high-entropy secret. Use an “ordinary” key derivation function such as HKDF or a function from SP 800-108.
The salt for derivation does not need to be random. Use a constant salt, with a different value for each key that you derive from the same root. Since you can use the same salt value for a given key on every device running the same code, you can hard-code the salt values in your code.
Don't make up randomness by downloading it or other unholy made-up methods. Use your operating system's randomness source, via your cryptography library's random generation API.


Store Virus/Keylogger on hardware component? Is it possible to store a virus or key logger or something of that kind on a hardware that transmits data?
I have recently bought a USB from Aliexpres and there is a bump on the cable, I did some research and apparently it's ferrite bead, but what if It isn't? Is it possible to create something that will do execute operation when plugged in?

I doubt that a little bump on the cable would be enough room to hide a listening or attacking device.

But it is possible to hide such a device in an usb cable. One well-known example is the Cottonmouth-1 used by the NSA.


How do browser injections work? I've heard many times that malware like Zeus, SpyEye and Citadel are able to do browser injections to steal credit card data. How do they do it? how do browser "injections" work? How are they able to tamper all browser data? Furthermore, why don't browser extension writers use something like browser injections to ensure compatibility with all browsers?

Additional question: Is there any source code you could look at as an example? You could make so much slick stuff with it!

These applications typically do not take data directly from the browser.

They analyze the current window (title).
For example if there is something like (shopping cart, checkout, transfer, secure https), then take user input (data are taken directly, not from the browser).
They can retrieve all user input and only send sensitive data to the server, the data is checked first by regulary expressions.

You can get keyloggers examples here:

http://www.rohitab.com/discuss/topic/14610-awsome-c-keylogger/

http://sourceforge.net/apps/mediawiki/pykeylogger/index.php?title=Main_Page


How to explain computer security to low-grade students? This is my first question here on Security, so please forgive me if I'm in the wrong place for asking this.

I am a computer science teacher currently teaching classes of teenage students age between 14 and 16. I want to give my class some lectures about "Computer Security"; I write it with quotes because they are not computer scientist at all, I just taught them a bit of programming, so what I need might not be exactly classified as "Computer Security".

What I am actually looking for is a good starting point (resources, books, blog posts, ecc.) to give them a glance about security from an end-user point of view like, for example, using smart passwords, good practices when surfing the Web, all those things that we, as computer guys, (should) use.

Can anybody help me on this quest?
Thanks in advance.

The chap who runs ISECOM (Pete Herzog) has an initiative called "Hacker High School" (he mentions them in nearly every email he sends out!)

http://www.hackerhighschool.org/lessons.html

There's an interview here about it:
http://www.securitybistro.com/blog/?p=3952


How can I determine whether or not a POS terminal violates requirements in the PCI DSS? The business I work for uses an Equinox Optimum T4220 (hardware number 060001) in dial-out mode. I see two search results1 for "T4220" listed on the PCI SSC's website under Approved PIN Transaction Security (PTS) Devices2. These listings look similar to what we have, but I do not know if these results indicate our device is PTS approved for the following reasons:

come from other manufacturers
have a hardware number in the 0630xx and up (ours is 060001)

I would like to determine whether or not this terminal violates the PCI DSS's requirements on storing  cardholder data. I am concerned with requirements 3.2.1, 3.2.2, 3.2.3, and 3.4.

I am also concerned with cryptography and transmission as I have no way to detect violation of these rules either.

How can I determine whether or not a POS terminal negatively impacts this business' attempt to become compliant with the PCI DSS?

I would say no, these devices are not compliant.

I did a search for "T4220", which found two listings on the PCI PTS site. Both are for hardware versions newer than what you have told us, and one of them is marked as EOL.

IANAQSA, but given that you cannot find the device you're interested in in the PTS, I would stop wondering about what other rules they may or may not be breaking and just replace them with something current.


Is "Please update/confirm your email address" actually helpful? Steam just asked me "Is this still your email address? [email_address_here]"

This is an on-PC app that I trust, so I'm 100% confident of its legitimacy.

I would like to know about its usefulness.  I get these kinds of requests periodically from dozens of apps or online services, and it's kind of a time-sink.

Easy enough to click "Yup, still my email address", 1 second and done.  Oh wait...
They want to send a confirmation email to that email address.
I have to fire up my email app, log in, find the email, copy the URL,
Fire up the other browser I use for this and paste the URL,
and then they want me to log in.  Ugh.  [Steam didn't, but many do.]

What is all this rigmarole really doing?  Does it really help my security in any way?  How does it help me for them to confirm an email that I know is good?  I don't mind being a partner in security, but this seems utterly petty.  Can you explain what good it actually does?

I'm only looking for InfoSec value.  I couldn't care less about marketing value, engagement value or UX considerations (it's a given those aren't good).

Besides the obvious UX values, this practice (if done correctly, like Steam) actually helps to mitigate stolen accounts.

This is what Steam does with all e-mails (both on update and periodically)

Ask user for email / Ask user is email is still valid for him/her.
Validate email selected with a one time token that is transmitted to given email address.
User uses 'link' / 'token' to validate email retrieval (this does NOT require authentication, nor does it AUTHENTICATE the user)
Steam notifies user that said email is now considered valid for the user and will be used for security announcements regarding its account (login tokens for 2FA, suspicious activity etc.)

Now, since a lot of people use their provider's e-mail account, there are many cases where this changes over time. These steps help to notify the user of what email is being used, validates that its mail server is still up to par and working for said user (this is done through strict mail delivery settings on the MTA of Steam). And that the user can actually receive notices when something security related happens to the user (a breach or loss of password or something).


Securing Internal Mobile REST API I am planning to create an internal API for mobile devices for a company.

They are planning to use this internal mobile app to get data from custom ERP, uploading contract, etc. Thus, it will be sending sensitive data. The user of this API is limited to their small number of employee, around 20+

Unfortunately, VPN is not a solution on this case. So, the API will have a public facing IP.

As an initial solution, I was thinking to create a REST API based on Node JS and place them in an public facing instance of AWS EC2.

To restrict the access to this internal API, I will try to whitelist the IP address range of their telco company and embed client certificate uniquely for each user on their mobile devices.

Also, I will implement authentication apart from client certificate, HTTPS, certificate pinning, HMAC based on device identity (IMEI, UUID), timestamp.

Is this approach (client-certificate) is less secure than VPN?
Is using Client Certificate authentication makes the backend safer to attack? (Let's assume that the certificate is never exported from the device)

Is there any chance that if I'm using AWS EC2, I could incorporate any other services in AWS that could secure this API and restrict them only to certain user?

Is there any safer way to secure this approach?

Is there any best practices to secure an internal API for mobile devices?
Nowadays, mobile app is pretty useful for mobile worker.
I was wondering how big companies overcome this problem to secure their mobile API?

Thank you. I would be grateful if someone could help me on giving suggestions.

There's nothing inherently wrong with using what you've described.  With certificate pinning, and strong user authentication you're going to be on par with most normal TLS web traffic.

Ensure that you're restricting communication in your certificates to only secure ciphers, setting a reasonable expiration date, and distributing the certificates in a secure out of band manner (don't just email the certs to the device).

Lastly the one pitfall I could see is the manner in which you do certificate pinning.  There's two approaches to 'certificate pinning'.  You could pin the entire certificate, and fail the connectin if that differes, or you could check that the keys used in the certificate stay the same.

While it will take more effort to check the keys, I suggest you go that route.  It allows you to update the certificate server side, and have the client still accept it assuming your key doesn't change.  This provides the security of expiring certificates whenever you want, but still maintaining pinning.

I would caution you about using AWS for sensitive data.  While your data isn't subject to regulatory restrictions, you still should consider the location of your data, what laws it could be subject to.  How well does Amazon AWS scub their drives after use?  What SLA does AWS provide?  I haven't used AWS personally, I'm just echoing what I've heard from others at this point.


Can the school see what you do on the school's Google account even on your own device and at home? I was on my normal gmail account that I always use, then this website opened my google docs app which was signed into my school account and it put some weird stuff on there like “i’m the hottest girl in school” weird messages.
Can the school see that that document got put on there although it was not my school laptop or their wifi it was just my gmail that opened the doc?

The Google account is administered by the school and they have access to everything created under the account and it doesn't matter what device you use or what wifi you connect to. It's all under the Google account.
But it is very unlikely that the admins will inspect every document unless what is entered triggers some kind of alert in their system, but that will likely be about illegal activities, porn, or bullying. If they even have those types of triggers set up.
So, no, “i’m the hottest girl in school” is not likely going to be noticed.


Can non-https assets be tampered with? Why load assets such as images, javascript, css etc, over HTTPS? Is it possible for these assets to be tampered with if I use HTTP? The only way I could conceive of tampering with HTTP loaded assets is to ARP poison the network and then inject packets for certain requests, but that kind of goes over my head. Can someone give me a clear example of how/why HTTP can be tampered with?

If you have a https page, but load some assets (JavaScript) over plain http, then:

Many browsers (recent Chrome versions, maybe also Firefox) won't
even load the script by default
an attacker can intercept the script, and replace it with — for
example — another script that will simply copy the entire <body>
contents of your https page, rendering https useless if the first
place. Or they can redirect the visitor to an entirely different,
attacker-controlled site. Most visitors wouldn't notice the change in the URL and continue interacting with the attackers site, potentially giving away their password or other sensitive information.


Are new AMD processors more secure than Intel ones? Since the discovery of Meltdown and Spectre, CPU security has been compromised and trust to the main manufacturers reduced, particularly Intel. 8 months later I wonder, what CPUs are more secure at this moment?
Why? Have the patches achieved the objective?
Personally, after the many security and privacy scandals published in the past year, my levels of information security and privacy paranoia have escalated.

They are both about equally terrible and still highly vulnerable to Spectre.

Unfortunately, you would have to have access to confidential design documents in order to even begin answering this question. From (quasi-privileged) anecdotal evidence, AMD used to be really bad with setting lock bits (MMIO/MSR defaults, if I recall correctly), whereas Intel puts a lot of effort into security. On the other hand, Intel has recently gotten rid of a lot of its security personnel and even outsourced the development of the ME to Israel  instead of doing it in-house (for MEv11, I think).

In terms of architecture, they are quite different internally. I can't say whether or not the deep internal architecture (e.g. Intel using ports to send data to execution units, AMD using pipes) is relevant to security, but their co-processors are quite different. Intel uses its Management Engine (now called the Converged Security and Management Engine, or CSME) which, while bad, is not nearly as bad as people make it out to be (it actually does not have direct memory accessnote, at least not by default, for various reasons, though it does have access to VGA and PS/2). The CSME was previously an ARCompact processor running ThreadX, but is now an i486/i586 hybrid (basically a little x86 core) running Minix. AMD on the other hand uses the PSP (Platform Security Processor), an ARM-based core which, if I recall, has absolute access to everything, including memory. Unlike the AMD PSP, the Intel CSME can be disabled, as people have recently discovered.

In the end, CPU security, and hardware security in general, is a new and emerging field. Both Intel and AMD are pretty equally vulnerable to all Spectre-class attacks (the gift that keeps on giving!), even if Intel is uniquely affected by Meltdown. I would say that, overall, both Intel and AMD are really, really insecure on an architectural level. ARM less so, and MIPS less so still. Of course, as we go to the more secure CPUs, we also come with lesser capabilities and performance. I personally go with Intel, mainly because there tends to be more research into Intel processors, so discoveries and leaked datasheets are far more likely to come from them than from AMD. That doesn't mean I consider Intel to be more secure. x86 security in general? Hic sunt dracones.


What is the risk of a packet being sniffed when travelling over the internet without SSL/TLS? We all know to use SSL/TLS to stop people eavesdropping on our connection, but how likely is it that an attacker will actually sniff your unencrypted password or cookie if you don't?
If we exclude sniffing on the local network (a pretty major exclusion I know, but indulge me), surely the attacker would need to have access to your ISP's servers, the server of the site you're connecting to, or one of the peering networks in between?

Has there ever been any research done on the incidence of this kind of attack?

It depends on your threat model.  If you're worried about big organizations who really really want to see your data, they're probably going to see it.  The hardware and software to do this is generally available to ISPs since they're required by law to provide for "Lawful Intercept" in many jursidictions: http://en.wikipedia.org/wiki/Lawful_interception  And unfortunately, the implementations by the router companies are pretty bad, as Forbes notes, so hackers may get access also.

Then there are all the other possible attacks, like DNS cache poisoning, phishing or routing (BGP) attacks, on connections that don't have the good endpoint authentication that SSL provides.  See e.g. how the Dalai Lama's organization was hacked.  Even security gurus figured they would be vulnerable to that kind of attack.

If no one (including insiders at your ISP or near your destinations) cares about you, you'll probably not be snooped on unless your local network is a convenient and easy target, like most wireless networks are.  But if sufficiently savvy and persistent folks (even individuals) do care, beware.


Why " Simple Integrity Property" axiom of Biba model protects data integrity? I am reading CISSP and more specifically the Biba model. Biba has some basic properties:

The Simple Integrity Property states that a subject cannot read an
object at a lower integrity level (no read-down).
The * (star) Integrity Property states that a subject cannot modify an object a a higher integrity level (no write-up).

I am a little confused about the first property.

The idea of the "no read down" principle is simply that information produced at a lower level may be tainted, and should not be consumed by a member of a higher tier in the hierarchy.

A classical example is that a priest may write a prayerbook for a farmer, but should not accept religious ideas from the farmer.


Is there an organization that reviews/approves crypto implementations? As I understand it, NIST approves crypto algorithms but doesn't cover specific implementations. I think I've read about IEEE approving hardware implementations of, e.g. AES, but I can't think of any organization that performs an analogous function for software implementations of crypto algorithms.

Corollary/follow up question: There are many open-source, freely-available crypto libraries; are any of these standardized/approved by any kind of regulatory body?

Since 1995, NIST has indeed also certified implementations, via the Cryptographic Module Validation Program (CMVP) that validates cryptographic modules for adherence to FIPS 140 standards.

OpenSSL is open source and the OpenSSL FIPS Object Module has been validated via this program: OpenSSL: Important Notes about OpenSSL and FIPS 140-2.

  The OpenSSL FIPS Object Module
  validation is unique among all FIPS
  140-2 validations in that the product
  is "delivered" in source code form,
  meaning that if you can use it exactly
  as is and can build it (according to
  the very specific documented
  instructions) for your platform, then
  you can use it as validated
  cryptography on a "vendor affirmed"
  basis.

Note that, as they say, "it's complicated".  So do check out those links carefully and be prepared for frustrating interactions between the technical and bureaucratic challenges.


Certificate based Access Control for Pub Sub messaging I'm extending an existing p2p/master Pub Sub framework to support additional security measures, via over the wire encryption and topic based access control. I'd like to use the x.509 certificates that I generate for nodes to communicate over TLS to also include the node's own specific topic policies; i.e limit what topics the certificate can be used to subscribe or publish with.

The current idea is as such:

Bootsrap

keyserver & master started
graph wide policy loaded into keyserver
new nodes without certs ask keyserver
keyserver looks up pub sub policy that match with node's namespace
keyserver returns node a cert with pub sub policy embedded

Out in the wild

only master is started, no keyserver
started nodes uses existing cert to register with master
master registers publisher or subscriber for requested topics
(master could try enforce to graph policy here, but master only notifies subscribers of where the publishers are, message transport for topics is still p2p)
subscriber attempts to connect to publisher
publisher scrutinises subscriber's cert to check to check it has permission to read topic
meanwhile subscriber does the same, checking publisher has permission to write to topic
if ether check fails, the connection is rejected!

I'd like to use apparmor's style of globbing syntax to permit novice users to simply generalize the access control over paths, this can be parsed and searched easily enough, and then embed the set of matching policies into the cert as perhaps a (human readable from common cert viewers? multi-line indented?) string. An example might look like this:

graph policy:

nodes:
  /*:
    topics:
      /logout{,_agg}:
        allow: rw
  /listener{,1,2}/**:
    topics:
      /chatter:
        allow: r
  /talker:
    topics:
      /chatter:
        allow: w

resulting node policy for /listener :

topics:
  /logout{,_agg}:
    allow: rw
  /chatter:
    allow: r

This way if the master node is ever compromised (but not the absent keyserver), nodes out in the wild still can't be fooled to talking or listening to anyone the shouldn't. Is there an existing certificate extension I should use or a particular form I should embed them with, or is there just a better way to go about this?

Ok, for posterity, here's my eventual approach for anyone coming along later finding this, and wonders what what I ended up doing while trying to to not obscurification the policy payload.

I essentially used the Certificate Policies extention to list the polocies applicable to the idenety.
Each element in the list the containes PolicyInformation the structues the policy identifier with the policy qualifiers.
The policy qualifiers is made to be a list of text strings, with each sting defining a applicable namespace scope using regex like syntax.

I used a nesting of of OIDs to map policy identifier to such actions as allowed/denied subscribable topic namespaces, etc.
ttps://github.com/ros/ros_comm/blob/e8568a493f039e6112884de733af00d289213a34/tools/rosgraph/src/rosgraph/sros_consts.py#L6-L8

When two peers connect, they use the certificate context from the TLS connection to acquire the other node's Certificate Policies extension data. Before the client sends the API request, it scrutinized the server's policy extension to check it is authorized to service the API call. If it is it will proceed, and if not terminate the connection.

When the accepting server parsis the API method requested, it scrutinized the client's policy extension to check it is authorized to request the API call. If is is it will proceed and dispatch it, and if not terminate the connection.

Some minor optimizations are done, such as sorting the qualifier themselves before embedding, and then later searching the dening related policy qualifier for matching namespaces requested in the API call before searching the allowed policy qualifier, as to terminate unwanted connections sooner.

There are some pros and cons in embedding policies into the same certificate used in the transport layer. I touch on that briefly in an additional write up here:
SROS: Securing ROS over thewire, in the graph, and through the kernel.


Why are simple packet filter firewalls insufficient for the protection of web applications? I was wondering why exactly are simple packet filter firewalls insufficient for the protection of web applications?

A simple packet filter firewall can only filter out packets based criteria such as source IP address and destination port number (e.g.80 and 443). But a packet from a trusted source IP address (e.g., an intranet host) and destined for port 80 (http) on the web server, may be allowed by a simple packet filter firewall. Yet that packet (well, that series of packets) can still contain malicious data, such as form input characters that make up an SQL injection attack against the web application.


Is encrypting a CRC with the plaintext ok? We're using encrypt-then-mac for authenticated encryption, and recently added a CRC32 to the plaintext. Are there any security problems with using a non-authenticated hash mechanism (for example, CRC32) for error detection (ie ensuring the message wasn't mangled, and it was decrypted with the correct key)?

So the format would be (|| is concatenation):

encrypt(msg||crc32(msg))||mac(ciphertext)

Does this result in a reduction in security, similar to using encrypt-and-mac or mac-then-encrypt?

I wouldn't do this and don't understand what problem you are trying to solve (unless this is a purely academic question).

Encrypt-then-MAC where we define ciphertext=encrypt(K_enc, msg) and sending ciphertext||MAC(K_mac, ciphertext) will detect any transmission errors or malicious tampering by someone who doesn't know the secret MAC key K_mac with overwhelming probability; e.g., if you used an 80-bit MAC the probability of tampering a message and getting the MAC to pass is 1 in 2^80 ~ 8 x 10^-25 which is negligible.  E.g., if someone generated a billion forged messages every second, it would take about 3.2 million years before they had an 8% chance of a single successful forgery (or about 26 million years before they have a 50% chance of a single successful forgery).

So the 80+ bit MAC provides strong security against successful forgeries or transmission errors by itself.

Meanwhile, the 32-bit non-cryptographic non-keyed CRC32 hash does not provide any additional integrity check against someone deliberately tampering with a plaintext message they can guess, at least with stream ciphers (or block ciphers acting like a stream cipher like CTR or the one-time-pad) where XORing a change to the ciphertext modifies the same bits in the plaintext.  E.g., as CRC32's do not involve any secrets, they can guess the original message m, calculate it's CRC32, take their intended tampered message m' and calculate it's CRC32, and then modify the ciphertext in transit to c' = c XOR (m || CRC32(m)) XOR (m' || CRC32(m')).  Granted, the keyed MAC provided by authenticated encryption does prevent this attack.  However, if you had a bad implementation that said provided information (either through an error message or change in timing) of a difference between the MAC failing and the CRC32 failing or when the MAC fails and the CRC32 passes, you would weaken the security of your system (and attackers could exploit this).

The only protection that the CRC32 could protect against is accidental memory corruption in your computer between calculating the CRC32 of the plaintext message and encrypting said message though the chance of that happening is also negligibly small.

In summary, if this is implemented poorly (e.g., the attacker can figure out that the CRC failed/passed even when the MAC failed), this can leak information.  If this is implemented perfectly, it would not provide any additional security as the keyed MAC is the part that would thwart a dedicated tamperer.