Storing customer credit card information for manual processing later For a solution that we are developing for the hospitality industry, we need to save customer credit card information, and show this to the hotel for them to manually process the payment later.

I have read all these questions and answers:

Storing credit card information for later manual processing
Storing credit card data on behalf of customers: and transfer the data later

The answer is pretty much "no, you can't do it." But the thing is, this is pretty much how it works within the hospitality industry, and me saying "no, you can't do it" basically means not being able to sell our solution to hotels.

I know many hotel booking engine providers that store the CC information for the hotel to view and process manually. My hotel clients also tell me that even booking.com does this. The catch is, they can only view the credit card information a certain amount of times before it vanishes.

Does this "only viewable a certain amount of time before vanishing" clause change the situation? Is there any way of getting around this to sell solutions to hotels without breaking the law and putting ourselves in danger (apart from processing the money through a payment gateway ourselves, hotels don't want this either)?

PCI DSS does not prohibit the storage of the Primary Account Number (PAN). Stored PAN just needs to be protected per PCi DSS requirement 3.

You can also store the CVV2 value at with the PAN until the payment has been authorised, at which stage you must securely delete any stored CVV2. May booking services will do this automatically after the first night of the booking - as the booking company is reliant on the hotel to tell them that the transaction has been authorised.

You can continue to store the PAN as long as you have a justifiable retention policy and it remains protected per requirement 3.

Of course - you will need to comply with PCI DSS and be assessed as a service provider, and you should realise that criminals like companies with repositories of PAN and CVV2 because that's good data to steal - so you (like all such booking intermediaries) will be a target.

BUT these is nothing within PCI DSS that prevents the business model you have described.


What are the benefits of federated identity management over bare bones public key encryption? What are the main reasons for having a federated identity system such as OpenID over having identities based purely on a public key?

OpenID uses an Identity Provider to confirm that a user owns a particular URL. Why not use a public key identifier. If the user can decrypt information encrypted with the public key, then they must own that public key. This would remove the need for identity providers and give users complete control over their own Identity.

The simple answer is that of course you could do that but then you would have to manage the infrastructure to cope with key management, and some organisations do exactly that.

It is a challenge, though, at large scale, so why not offload some of that onto a trusted provider? That way they can focus on the identity management and you can focus on your business.

Simple outsourcing model in many respects.


NFC - Felica / NXP (Desfire EV1) or ACOS3 which is more secure? I am new to NFC, and just have been researching on security from different manufacturers, trying to find out which system is more secure with their password protected area.

I only know that Desfire EV1 has the 3DES/3KDES, but totally no knowledge on Felica or ACOS, wondering if anyone has any info on it. I know of the older Desfire is known to be pretty weak in security, but EV1 has been ok up to now, how does it compare against Felica and ACOS?

If I have hidden data on a card (protected by password), and can only read the data when password is entered. Which system is the most secure for that?

DESfire before EV-1 (which was introduced in 2002) should indeed not be used any more and has not been recommended for use for more than five years. DESfire EV-1 (introduced ~2007) adds countermeasures against differential power analysis (which the non-EV-1 product lacked, leading to its eventual downfall), and AES-128. Since ~2014 there's even the newer DESfire EV-2 with better key management to delegate card space to third parties, proximity checks and better privacy options.

Felica is prevalent in Asia, but only added AES in around 2011.

I know nothing about ACOS except for its existence.

Note, if it isn't obvious: I'm biased towards DESfire EV-1, having worked with the cards in several projects.

For your basic problem of just storing data on a card that is to be read after authentication, disregarding all other things (authentication of data from the card, confidentiality of the data while in transit, etc.) it is likely that either system will work (and thus be indistinguishable).
If you eventually want more, you probably don't want a niche product like ACOS (except of course if it happens to hit your niche exactly), so DESfire or Felica. The latter is mostly documented in Japanese, so if that's a problem, that's a problem.


Is some kind of CSRF possible using img/script tag to read sensitive information Let's say i have an API at https://mysite/api/getSensitiveData that:

Uses GET
Protected with cookie authentication
Returns JSON with some sensitive data

A bad guy creates a site on his server that has an image tag:

Now browser will execute this request and send the cookie and data will be loaded (as far as I know at least) and then since it's not an image nothing will be shown.

But the request was executed on a site where a bad guy controls javascript. Is there any way that the response can be read from image, some interception of requests or some other method?

P.S. Maybe there are some other similar possibilities, not necessarily img tag?

With just an image tag - no.  For the attacker to be able to gather data from the API endpoint and return it to himself, he would have to have javascript on the page under his control.  With javascript/ajax requests the browser will still pass along cookies and therefore authenticate his request, potentially allowing him to receive a response and then send it off to a new server.

However, any attempts to do this will run afoul of the same origin policy in the browser.  This states that if a script requests a document from a site with a different host, port, or protocol, the response will be denied from the script unless it is explicitly approved by the destination site.
 The most common way to approve cross-domain requests is via CORS.  As a result, the only way an attacker would be able to actually read the response from your endpoint and retrieve the data is if you (the domain owner) have explicitly told CORS to allow credentials and also white-listed the domain name that the malicious javascript is running on.

To get around that restriction the attacker would have to get their own javascript to run on your domain, but at that point in time we're talking about an XSS attack, and you're pretty much hosed.  There are ways to prevent data from getting back to an attacker even in the event of a successful XSS attack using well configured CSP headers, but CSP headers can be tricky to get right and they don't yet have broad browser support (in particular IE).

The closest analog to what you are talking about is XSSI/JSON hijacking.  These are different techniques to bypass same-origin-policy restrictions in the browser:

http://www.thespanner.co.uk/2011/05/30/json-hijacking/

However, the techniques that allow these restrictions to be circumvented have largely been patched in modern browsers, making the vulnerability much less relevant:

https://stackoverflow.com/q/16289894/1921979

It is always possible that additional such weaknesses can be found in the future, in which case there are some techniques to protect against XSSI (h/t Xavier59):

https://security.stackexchange.com/a/110552/110133


Sniff plaintext password written in /tmp directory I was recently reading about Ansible and the way it manages the sudo passwords. More specifically:

  When using become_user to a user other than root, the module arguments are briefly written into a random tempfile in /tmp. These are deleted immediately after the command is executed. This only occurs when changing privileges from a user like ‘bob’ to ‘timmy’, not when going from ‘bob’ to ‘root’, or logging in directly as ‘bob’ or ‘root’. If it concerns you that this data is briefly readable (not writable), avoid transferring unencrypted passwords with become_user set. In other cases, /tmp is not used and this does not come into play. Ansible also takes care to not log password parameters.

Isn't this a security risk? Could a non-privileged user write a watchdog script that sniffs the contents of newly created files in the /tmp directory?

A possible attacker can also use the inotify mechanism of the linux kernel to track the filesystem events in the /tmp directory.

If a new file is created, create also a hard link to this file. It will result that the file will still exist on the hard drive, even after the attacked software thinks it was already deleted.

This is an event-oriented solution, which happens on the spot after the file creation, it is invisible for the attacked software, and getting the event and creating the link takes only 2 kernel calls. It is faster as anything what the attacked software can do.

The required code is around 30 lines in C. Most rootkits probably contain this feature, but in a non-hardened environment you don't need root for that.


In what situations should a node ping/not ping? I was recently looking at a network in which the client-machines could access a webservice endpoint but could not ping it.
And there are other machines that can ping the webservice endpoint, but which do not utilize it. However, these other machines do connect to service the client-machines, and of course, can ping both.
All machines in question are on a private network that extends to private and public physical locations.
So, why would some of these machines DROP packets and others ACCEPT them?

ICMP can be dropped for a variety of reasons to protect the service. And there are obviously clear reasons why ICMP is useful.
If you take the stance that you only allow services that you have a stated reason to enable, then the default would be to drop ICMP, and only allow it for specific reasons. Firewalls always start with a default DENY, and then you build ALLOW rules on top of that.
In your example, it appears that there are admin-type machines that need to ping everything. This is not unusual for admin machines.
Client-type machines likely have no reason to ping the service, so that would fall under the default DENY because you would not craft an ALLOW rule for the clients without a reason.


How to know if my webcam is being used to spy on me? Last month I was browsing the internet, and clicked on a link on a website. If you click a link at this site ususally a pop up comes up. Therefore I knew a pop up was going to come up and I closed it as usual. But for that brief second my webcam turned on. Ingnoring it I continued working.

A few days back this happened again and I installed antivirus (which I didn't have before). Nothing came up, but now I'm very worried that a hacker has installed malware on my laptop and is secretly spying on me by disabling the led, and that the led turning on was just to take a pic.

But on the other hand, if someone goes through so much work (like installing malware without me installing anything, etc) he would have held ransom against me already, as my laptop is on all day in my room and I change in my room. But he didn't.

Is there any way to identify if something like this happened?

It's extremely unlikely. For a start, many of the camera-enable LEDs are driven by a microcontroller on the webcam itself, switching on when the camera is in use, so the driver doesn't make a difference here. In fact, last I checked, most webcams use a generic driver (e.g. WIA) for image capture.

If you're really worried, install a privacy cover over the camera.


Methods of mitigating threats from keyloggers I am concerned about keyloggers being installed on my system and transmitting sensitive data out of our network.

Is there a common method that such malware uses to send its collection back to the hacker? For instance, do they generally contact a server directly and separately, or utilize an existing connection through a web browser or other benign program?

Assuming that prevention methods (anti-malware programs) are in place but have failed to stop a malicious installation, what further steps can be taken to prevent data from being transmitted?

One thought I had is to install a firewall such as ZoneAlarm to warn of any new connection attempts, but if the keylogger uses an existing trusted connection that would be of little value.

Is there a common method that such malware uses to send its collection back to the hacker? For instance, do they generally contact a server directly and separately, or utilize an existing connection through a web browser or other benign program?

Not with any consistency there isn't. Here's a range of methods Mr Hacker could use:

Listen, a-la simple shell script. Basically this method relies upon the attacker probing for then connecting to the port in question. Fairly naive and easy to mitigate - only allow outbound connections, ever. Do this in spite of NAT as IPv6 will make those NAT defences disappear.
Outbound connection by a component of the malware. These actually break down into further sections:

To some odd port number, like dodgy.site.example:1337. Clearly, you should be blocking outbound connections to ports you don't need, but in the context of a home environment this might not be practical.
Via email. Either to a known smtp relay, dedicated smtp relay or directly (MX lookup + straight to the mailbox). In any case, do NOT allow traffic out on port 25 or even 587. Identify either a local trusted relay or a remote one and only allow connections on port 25/587 outbound to that machine. Enforce TLS and authenticated login.
Looking like a legitimate protocol, e.g. I've connected to https://dodgysite.example but not talking that protocol. SPI/Deep packet inspection may find these sort of things, or it may not.
Actually being a legitimate protocol. Does an HTTP POST look suspicious to you? Me neither, but given I just want to get data somewhere, CGI will handle collection nicely and HTTP POST is probably allowed everywhere. Would make an ideal data submission vector.

In both of the above two cases, an authenticated proxy server might help, simply because it reduces the chance of an outbound connection as not all malware is capable of detecting or using proxies.

Several improvements can be made on these from the malware perspective.

Hooking another application and executing any of the outbound/inbound connections in the context of that process.
Using a rootkit to simply refuse to allow local (as in on the system) scanning software to even know the outbound connection exists.

What is the solution?

Well, probably the best way is to keep your computer clean in the first place. Prevention is absolutely better than cure, especially in the case of a kernel level infection. However, knowing you have a problem is clearly important too, so:

Intrusion detection systems.
Monitor logs for suspicious activity. Firewall logs, operating system logs etc. See IDS, but do it yourself too.

That's about it. If all the ports you don't need are turned off and you're passing all connections you want through proxies or reasonably scanning them, the best you can do is reactive defence in this case.

From a personal perspective, I am very much interested in Mandatory Access Control. I honestly think a lot of benefit can be derived from designating specific resources an application requires and I say that as a programmer as it helps define specifications. If you're using a platform capable of some level of MAC you might be interested in investigating it. I've also recently answered a question on Sandboxie which looks like an excellent piece of kit for Windows.


How to display friendly notification about no TLS 1.0 support in browser A browser that only has TLS 1.0 support won't be able to establish an HTTPS session with a server that has only TLS 1.1 and TLS 1.2 support.

This typically results in a cryptic (to a normal user) error about a cipher suite mismatch or in IE even misinforms the user.

IE 10 says,"•Make sure TLS and SSL protocols are enabled. Go to Tools > Internet Options > Advanced > Settings > Security"

IE 11 says "Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to www.xyz.com again."

Is there a way to display a more informative message or page to a user in these cases that I am overlooking. I'd like to at some point disable TLS 1.0 and not have browsers that are still fairly common directing users to do things like enable SSL as that might cause them to go check all the available SSL and TLS boxes including SSL v2 and v3.

You can't get a nice notification to the user without establishing the TLS connection first. This means that your server or some middlebox (load balancer) in between must still be able to talk TLS 1.0. But you then could then check the protocol version of the client inside your web application and show the nice notification there. But, if and how this can be done depends on your web server and application framework.


Is it easy to create persistent programs that run before Android's boot? (in firmware maybe) I've been wondering about which level of trust I can apply to a used phone bought from someone else. I can easily unlock the bootloader and flash a brand new Android. However, what about firmware customizations? What if there is something bad that runs before Android boots?
I'm not talking about something that the manufacturer plants in the phone, but something that the user or malware might have done.
It's more a question of how easy it is to run things on Android beyond the flashed image. Can anyone do it with basic tools, or is this something hard, exploit-related that might be possible on some specific brand?

If the bootloader is locked, all android partitions are verified by android verified boot (AVB) and android bootloader (ABL) is verified by secure boot which is enforced by chipmaker in production SoCs. Devices with Qualcomm Snapdragon SoCs, Qualcomm's Primary Bootloader (PBL) of SoC verifies Xtended Bootloader (XBL), XBL verifies ABL and ABL enforces AVB.
To break this chain of trust, the attacker can exploit a vulnerability somewhere in the chain to bypass signature verification. One can also tamper with PBL on board. While modifying it may be considered feasible in theory, it is not scalable. PBL is burned on CPU die and its public key is stored in eFUSE which make it tamper resistant. Android has infamous fragmentation problem, most android devices never receive timely updates and new vulnerabilities remain unpatched. Some of the critical vulnerabilities in chipmakers' bootloader and android bootloader were found in the past which could be used for persistent malware and bypass of secure boot and AVB.
If your device's bootloader is locked and has been factory reset then it is running stock image otherwise the device would brick on first boot. The device can also run with custom root of trust where AVB key is user generated. This allows user to make its own modifications and re-sign images to enforce custom AVB. You can see the verified boot state of the device in bootloader mode.
Verified | SelfSigned | Unverified | Failed


How Is It Possible That an App Connects to 0.0.0.142 IP Address? I regularly review connections being established from apps in my phone to external services. Lately, I found Facebook connecting to 0.0.0.142. So I deleted Facebook for Android app. Now, I just found that Instagram is connecting to the same weird IP.

Questions:

What does this IP mean?
Could this be a symptom of an exploited phone?
What are other methods to know more about the effects of this attack (if it is)?
How do I remedy the problem?

Screenshot

http://www.speedguide.net/ip/0.0.0.142

  Reserved and special use addresses:
  0.0.0.0/8 - Current network (only valid as source address) RFC 1700

As it says i't just a way to represent the network in which you are. I think you shouldn't worry about it, but I'm not an android expert


Google login button - what prevents an rogue app from stealing a token? Here are steps to setup a Google login button on a web client:
https://developers.google.com/identity/sign-in/web/sign-in

When click on the Google login button this pops up:

All the interactions are between the IDP (Google) and the user's browser.

Is there anything that prevents a malicious app from copying/modifying the source code of the app, fake the good app and steal a valid token from the IDP when the user signs in?

When the user selects an account to sign in with, they are taken to a login page (if not currently logged in) and then/or sent "back" to the app in question, along with the SSO token. I say "back" because the user will be sent to the URL that was specified when the app was configured for SSO. That won't be the attacker's site; the attacker won't be able to see the SSO token.

Google (or other IDP) could also attempt to check where the user came to them from (checking the Referer header) to ensure that it's not some other web app spoofing the legitimate app's client ID, but that is probably not needed.


How can I detect unencrypted self-executing code in JPEG images? Assuming that I have an infected image containing a self-executing malicious code that targets my image viewer and executes when I open the file. Supposing also that my computer is completely clean and not infected by another malware that can read the hidden code in the image, this code could not have been encrypted. Thus it must be unencrypted in order to execute, which means it is somehow visible.

What methods can I use to detect it ?

This is the easy case for anti-virus software.

However, do not suppose that a malware has to be unencrypted to be executable. Polymorphic code brings self-decryption to malwares, it can be helped by Metamorphism to ensure that even the very start of the decryption routine, since there must be indeed a unencrypted starting point, does not present any recognizable constant pattern.

It is trying to fight such kind of methods which make anti-virus software to be complex programs.


Efficient way for finding XSS vulnerabilities? Manual (reliable) way: Put string containing characters that have special meaning in HTML into some parameter of HTTP request, look for this string in HTTP response (and possibly) in other places where it's rendered. However, this way is very long as all actions like putting inputs into parameters and finding those strings in HTTP responses are performed manually.

Automated (fast) way: Run security scanner like Arachni. But it seems (after looking at code) that it will find vulnerabilities only in usual contexts and won't treat specially CSS values, JS code etc.

So what is a more efficient (fast and reliable) way for finding XSS vulnerabilities? I'm interested in changing manual way into semi-automated to make process faster

DOMinator Pro is a great semi-automated tool for identifying DOM XSS.

  What is DOMinator?
  DOMinator is a Firefox based software for analysis and identification of DOM Based Cross Site Scripting issues (DomXss). It is the first runtime tool which can help security testers to identify DomXss.

  How it works?
  It uses dynamic runtime tainting model on strings and can trace back taint propagation operations in order to understand if a DomXss vulnerability is actually exploitable.


Isolate dangerous applications in VM I want to harden my personal computer against possible security threats.

One thing I'm considering is to for example put my torrent client inside a virtual machine, together with the applications used to execute any files I might download. I would also put a browser in the VM for visiting webpages I don't trust.

Does anyone do this? Does this approach make sense?
If it makes sense, are there any easier ways of getting same effect?

I'm aware that virtualisation is not 100% safe but I assume it greatly complicates matters for any potential malware/hacker.

Yes, this approach make sense. There's even a Linux distribution called Qubes OS that does exactly this, with extra care taken so that applications cannot exit their VM isolation.

I would recommend you to read their blog articles if you want to learn more on the subject.


How does "Google password monitoring" work? Google Apps has a feature to monitor users' password strength and notify administrator about it. Google help says:

  View the length of each user's password along with a graph showing its
  relative strength based on other criteria. The graph's indicators can
  assess password strength upon user login. The indicators change over
  time in relation to your password length requirements and common
  passwords known to be vulnerable.

Does the fact that indicators change over time means that Google actually keeps plain-text version of the passwords?

No, and the documentation you quote demonstrates that.   Specifically:

  ...The graph's indicators can assess password strength upon user login...

If they need the user to log in in order to assess the password strength, that's because that is the only time when they have the password in a form they can examine.  That precludes them from storing it in plaintext (or encrypted using a key they know) which would allow them to examine it at any time.


CCM for IoT - choosing L and M Other developers have developed a custom in-house RF protocol for our upcoming IoT devices. I would like to replace our use of AES-CTR with AE - our encryption library supports CCM which should therefore have the lowest barriers to implementation.

CCM requires two tunable parameters - L and M, with corresponding security tradeoffs. Given a preference for single key negotiation and short transactional messages, what are good values to choose for L and M?

As the devices support scheduling, I estimate an upper limit of roughly 100 messages per day over installed lifespan, which I might generously estimate at 30 years. Messages are typically under 10 bytes (the protocol supports up to 64kib). We wouldn't be using associated data.

I would also like to choose nonces at random, in part to save on storage synchronization and in part because I'm not 100% confident I understand the statement at Wikipedia: "One key insight is that the same encryption key can be used for both, provided that the counter values used in the encryption do not collide with the (pre-)initialization vector used in the authentication." clearly. This should then lower the expected lifetime of the key due to the birthday paradox.

Will this provide adequate security if I pick L=2 and M=8? Or would I need to add key renegotiation if we expect a lifetime of 30 years?

Edit: please note that I am much more concerned about the choice of L, which appears to create a security tradeoff (nonce length vs message length), than of M which is a more typical performance/security tradeoff.

The authenticate tag (M) should be as large as possible. The larger it is though, the more overhead for transmitting a single message. Generally you would want the tag to be at least 80 bits, which is 10 octets. Ideally, you should have a tag of 128 bits, or 16 octets, or M=16. A larger tag makes it more difficult for an attacker to forge messages without being caught. A 128 bit tag results in each forged message having a probability of 2-128 of being accepted, resisting a computationally-bound attacker.

The message size (L) specifies how small the nonce will be (nonce size is 15-L octets). You want a random nonce to be large enough the birthday paradox is not an issue. For this, 96 bits, or L=3, should suffice. This size is the standard used for GCM under a random nonce, which has proven to be quite secure. Since 100 messages per day over 30 years results in only a little over a 106 messages, it would also be safe to use a 64 bit nonce in theory, but 96 bits will prove safer if more messages are sent.

You should be generating a new session key using asymmetric cryptography each time the device is turned on. This will prevent an attacker who records messages from being able to retroactively decrypt them after obtaining a single master key as can be done with WPA and WPA2. This is referred to as forward secrecy, and ensures that an attacker cannot retroactively decrypt old sessions. Forward secrecy requires the use of ephemeral DH or ECDH for key exchange, rather than plain RSA.


Security best practises for my first ever Node, Mongodb, Nginx production app on a Ubuntu VPS So as the title says I'm just deploying my first ever app in production.

Because I don't have experience, I was told to ask someone who knows this stuff.

So how should I ensure the best security for my VPS and for my app?

For now I did everything from this link (about node.js)

https://expressjs.com/en/advanced/best-practice-security.html#use-cookies-securely

and from here about mongodb: https://docs.mongodb.com/manual/security/

For the VPS all I did was disable password auth, root auth and use RSA authentication.

I am also thinking about a firewall, but I don't really know what to use. Is 'ufw' sufficient?

Also, what ports should I block? I'm thinking about blocking everything instead of the one I'm running SSH and the one for hosting my Nodejs apps. Would that be okay?

Also, if I run my nodejs app on port 8080, can I also run MongoDB on that port too? Why would I want to run it on a different port and leave it open, when I can run it on 8080 too?

Sorry for the big list of questions but I have no one to ask about this stuff. I feel like this would be a good place to ask all of these things.

I recommend to have a bastion host to access your server via a SSH-port forwarding agent to tighten the SSH aspects.

Usually I perform OS hardening images using CIS Benchmark guide.

Always focus on 3-tier architecture concepts. I don't recommend to run on the same ports on the same node. You can use docker concepts for your usage.

I use the following:

Nginx for Reverse Proxy (Behind NAT or Direct Public IP) with SSL configuration and its respective encryption algorithms. (Port 80/443)
NodeJS for application tier (parsed from the Reverse Proxy's proxy-pass to custom port, similarity to 8080) using internal IP.
MongoDB connector (Mongoose) on another NodeJS application layer with different running port as middleware. (Port 8000)
MongoDB Server with custom port (you can also use the default port 27017) which only allow the TCP communications within the internal subnet of your docker containers.

Additionally, I don't use ufw. I use ConfigServer Security & Firewall (csf) for easier management for the server(s) since by default it is whitelisted (Deny) and on Test Mode to understand your usage.

Optional: You can use HAProxy as load balancer on top of Nginx and/or your application and db tier dockers.


Will it be safer to use self sign CA and client certification in the company for a private website? Our company have 10+ private websites and 20+ person and need to open a different one automatic when the developers are testing some functional. We do not want anyone outside the company to view the content of the private websites.The websites is access with ip and port.Those websites have public ip, can be access from any place.

So there is two options:

We can open http websites and use a http basic auth with a fixed username and password to login. When someone leave the company the password will change.
We can create a self sign CA and a client certification , and use that ca to sign a https server certification to the websites, and the websites need the client certification to view. We will continue using the fixed username and password and http basic auth in the https websites.

Will option 2 safer than option 1? Or it is just a illusion of safer because of https?

Is there any bigger safe problem in the option2?

additions

We put the server of websites in big datacenter with public ip to access data faster, put the server internally will make it access the data too slow to work. So the websites will access from public ip, I do not know any way to prevent it.
Using vpn can make the websites easy to not work when the vpn server itself dead. And it make the end user difficult to use the websites, as we already use vpn to do some jobs, two vpns is impossible in some operation system. (like android/ios)
We use the fixed username and password to prevent the left person have the access to the private website. They are fixed , so we can use less time to manage it.

I'm coming from the assumption that you don't leave any backdoor open in either of the methods, and choose high-entropy passwords for Basic Auth. In that case, the biggest difference between the methods is that HTTPS will encrypt the traffic and prevent Man-in-the-Middle Attacks, making it impossible for anyone to eavesdrop, whereas Basic Auth will not.

So in that sense, the HTTPS based method is more secure.

You could get the same benefits regarding encrypted traffic for Basic Auth by adding HTTPS with a certificate that is commonly trusted by browsers (not requiring client-side authentication apart from Basic Auth)

In practical terms, you don't have to have the same password for everyone in the company. I think this is the greatest security flaw apart from any method, if security is a concern. Instead, you could have individual accounts (or client-side certificates) for each person. If a person leaves, you only have to invalidate that account. It also gives you the ability to detect who, and from where, uses certain accounts, and if an account is identified as compromised, you can close that account without affecting others.

The best of all worlds, also counting practicality, would be Basic Auth with individual accounts combined with a commonly trusted HTTPS cert.

If you are willing to compromise security, for example by having a single account for everyone, quote "so we can use less time to manage it", then I don't know why there is a debate about TLS/Basic Auth in the first place, because no encryption can compensate for an insecure handling of information.


PKCS11 key pair generation - attributes MODULUS_BITS and PUBLIC_EXPONENT We're using a rather low-level PKCS#11 interface and are trying to generate a key-pair for RSA with it. We're using the mechanism RSA_PKCS_KEY_PAIR_GEN (0x00). Among others we have copied the following two attributes from one of the interface's code samples:

MODULUS_BITS (0x0121) = 1024
PUBLIC_EXPONENT (0x0122) = { 0x01, 0x00, 0x01 }

We're pretty sure that the used values are demo values only and we need to use different ones in our production code.

Two questions actually:

Is MODULUS_BITS the length of the generated key? I.e., is 4096 a good value nowadays?
Is PUBLIC_EXPONENT really required? What is it?

Yes, MODULUS_BITS is the key length. 4096 supposed to be good nowadays.
PUBLIC_EXPONENT is public and { 0x01, 0x00, 0x01 } = 65537 is widely used value since:

it's prime
it's not too short
it's not too long and contains only two '1' in it's binary representation - that makes binary exponentiation fast (you can encrypt or check signature quicker)

PUBLIC_EXPONENT is really required in the RSA algorithm, but it's possible that if you omit it, the generation algorithm would use 65537 by default.


Handling security with sub-domains pointing to boxes Generally, despite running hardware+software firewall combos and keeping every layer 7 aspect of the box secure, I don't like to disclose the direct IP addresses of our servers to the public as a further layer. That being said in order for mail to be sent most ISPs are requiring that the PTR record for our server match up with an A-name (forward resolving) record. If we do this that would expose our servers IPs because anyone could simply resolve workerx.cluster.x.com to the IP address of our server which isn't very difficult to guess. Is this a serious concern, or is this a fine thing to do?

You shouldn't be exposing your server's IP, but your firewall's IP through DNS ...


Can the Belkin WeMo switch be attacked without the attacker knowing my WiFi password? The Belkin WeMo switch lets you turn on and off electric sockets over WiFi using an app. Apart from the WiFi password, is there another potential vulnerability of this device that could let an attacker control my socket?

Most of the remotely accessible power strips I've been looking at for a current project have either http or telnet access (no encryption on either) for control so any time you access it, you're sending credentials in the clear.

They are in the IOT minimum security zone, anyone on the local segment can packet-sniff your credentials if they're determined to flip switches. So the only protection you have is often a sniffable password if they don't have the ability to change from a hardwired admin and  user account name. And often, no brute force timeout either.

And my experience on contacting the manufacturer about minimal security is "we keep having customers ask these questions, but the unit doesn't really have the processing power to enable (ssh, https, bad login timeout, etc.)

Specific to WeMo, it uses UPnP which has security concerns discussed in this question on security.stackexchange. One of the recommendations to increase router security is to turn off UPnP and manually configure port forwarding.

WeMo had some security issues with its cloud based control, firmware updates and protocol used back in 2014 which have been patched.

Several websites on the internet discuss scripts using curl to post SOAP commands to the WeMo device to control it. That's unencrypted http over whatever port (49152/49153) the device is set to and via UPnP port opened through the router for remote access. No authentication is mentioned in these scripts either, so you use UPnP to open a port for internet access and there's no gatekeeper for toggling the device.

WeMo appears to hide behind a phone/tablet App via a cloud service that requires UPnP to open a forwarded port on your router for communications. Getting any information off their website as to how this communications is protected other than how easy it is to use is proving difficult.


Check integrity of GnuPG inside of GPGTools? Is it possible to check the integrity of the GnuPG files inside of the downloaded installation package of GPGTools?

I know how to check the integrity of the .dmg file (compare the SHA1 hash), but I don't know how to check especially that the GnuPG binaries inside of the installation package is safe?

Of course I know I can reach the files inside of the package, but how to verify the binary files?

The content provider (GPGTools) provide no means to check the integrity of the files inside the package; they provide no hashes/sigs, so you have nothing to compare to. They appear to compile their versions/ports of other open source projects, so even if you try to compare the check the binaries against their counterparts from another content provider, the check will most likely fail.

Since they provide the package and page showing the sig over HTTPS, you can trust that they both come from GPGTools website and you can trust that you're being handed the authentic package.

Now if you don't trust the source of the package (GPGTools), you probably shouldn't be using their ports/packages in the first place.


How effective is Opera Mini's encryption? Can it hide activity on a WiFi network? I'm curious since I discovered the nature of how browsing works in Opera Mini. A URL request is sent to Opera's servers, they download the page then compress it to lower bandwidth. They use a file format that is only used by Opera Mini. I like to visit websites like reddit's WTF and I don't think my university network admins would appreciate seeing that in the history.

First off, the service you are talking about is Opera Turbo, which the web browser, Opera Mini, makes use of.

I would imagine that network admins at a school do not care the least about what gross/weird sites you look at in your free time as long as you are not using a ton of bandwidth or breaking the law. I know that isn't your question, but it is still relevant. I'd read your university's terms of use and then not really worry about what you are looking at as long as you don't violate it.

Also, this is important to understand as there is a lot of old information out there:

  If you browse a secure site, like your bank or email, Opera Turbo stays out of the way. Your sensitive data is sent directly between your device and the secure site.

source

That means that Opera Turbo does not break end-to-end integrity. (That's a good thing!)

Quick test:

When I visit reddit.com/r/netsec, this is what Fiddler (a packet capturing tool) sees:

GET http://sitecheck2.opera.com/?host=www.reddit.com&hdn=1T%2Bc%2BVh6YJohgWpVDp9S7Q%3D%3D
200 OK (text/xml)

CONNECT http://af.opera.com:443
200 Connection Established ()

CONNECT http://autoupdate.geo.opera.com:443
200 Connection Established ()

First, it makes a request to sitecheck2.opera.com which reveals the host... and possibly the entire URL you want to visit. I think this is some kind of anti-phishing thing from Opera. In my opinion, this undermines a lot of the anonymity you are expecting to have with this solution. Then the connection to af.opera is established, and you don't see any new traffic.

I am not going to attempt to do some kind of security audit. I don't have the knowledge/skills/time to do so. The basic answer is that you don't use Opera Mini for this, you use Tor or some other SSL tunneling service. Again, this could be a clear violation of your university's Terms of Use. Even Opera Turbo could be a violation if they ban all proxy servers.


Encrypt Items With Single Key or Use KDF+Salt To Encrypt Each Item? I'm currently planning the development of a system where extremely sensitive information for individual users would be stored. There are currently two approaches being discussed. In order to make it more concrete, let's say we're encrypting each user's social security number (SSN):

One time, generate a global encryption key/iv. Encrypt each SSN in the database with the same encryption key/iv.
One time, generate a global secret. Use global secret and a KDF (such as PBKDF2 with a per-user salt) to generate a unique key, iv pair for encrypting each user's SSN.

I don't know enough to advocate either way, is there any advantage to (2) over (1)?

EDIT: I'm mostly looking for help weighing the general pros and cons of each approach. Namely, does (2) provide any additional security over (1) given that both rely on a shared global secret?

Given the property of SSNs - beeing all guaranteed to be different - there is not much added in terms of security using the second approach, if the used mode of operation (which you didn't disclose) allows IV reuse.

But please let me suggest a third option: you should be using a Hardware security module (HSM) for this.

Your question does leave me with the impression that you are trying to solve this programmatically, yet there is a huge problem with that:

If your application is to use the SSNs, there has to be the key somewhere accessible. Encyption of the SSN should probably be deployed to keep the data safe in case one of the hard drives or the stored data gets leaked.

When this happens and you keep your key with the data, there is nothing protecting the data anymore. A data dump would most certainly also contain the key, unless an HSM is used.


Mobile Website Security I have a school project with the topic name
"Mobile Website security" which is a little confusing. The task is to write a report regarding the type of threats and the defenses against these threats

As from what I understand, a mobile website is basically a website that is scaled down to fit onto a mobile phone.

After googling, the word mobile security appears quite a lot, but it doesn't seem to be in the same category as a mobile website

So my questions are:

Does the security of a mobile website and a "full" website differ?
Is mobile security the same as mobile website security?

I've noticed nobody actually answered this question and while the questioner might be helped already, others might have the same question.

There is no significant difference between a regular website and their mobile version. You use the same technology and therefore the same risks apply to these websites. Of course, there is a big difference between securing a regular website and mobile security - They are fundamentally different.

In this specific case; asking your teacher to clarify the assignment might be your best shot. This could be the answer to your second question "Is mobile security the same as mobile website security" as there is no such thing is 'mobile website security' in the security industry unless your teacher meant the same.


Bios passwords "easy" to find I have read that bios passwords are sometimes good--or bad, if there is a default. Places mention that these passwords are pretty much just available through google, but I can not find them.

Where would I find them?

A list of BIOS passwords is here. Note that while BIOS passwords help to protect to a certain extent, they are no barrier when someone has gained control over a computer. They could use utilities like flashrom to change the password, or even embed a rootkit into the BIOS flash chip.


Would it matter if my miner was hashing random vs incremental values? I'm working on my miner for my "game" site that's basically a pre-image attack from a hash posted online. You submit a hash input, it's hashed, and your score is the hamming distance (the number of bits that differ) between the two values. If it matters, I'm using Skein-1024 v1.3

My miner up until now has been incrementing a value and hashing it. Increment, hash, increment, hash ad infinium. I wrote it so that when I close the miner, it saves it's current highest value that way when I restart it I won't start back over at 1 and hash all the same inputs again. I can pick up where I left off. This has proven to be some what successful. However, I'm curious if the miner might be more fruitful by generating random numbers instead of incrementing.

It seems to be a hard metric to measure. I know that most hashes will output wildly different values if their inputs are off by only a bit or two, but I feel that by incrementing the value I hash I'm usually only a few bits off. If I randomly generate values I'll probably do fewer hashes (because random number generation is more intensive than a simple num++ increment) but my gut tells me that I'll have a more diverse set of inputs and that it might produce a more diverse set of outputs. I know not to trust my gut without reason about this. I feel crazy just typing it out.

I also know that if I increment I'll never end up hashing the same value twice. Random is capable of that although the odds of generating the exact same 64 bit number twice is slim.

Can I expect different qualities of outputs from my miner by hashing random values instead of an incrementing value?

FULL DISCLOSURE: I am the owner and operator of the site above. There are no ads or even analytics on the page.

I'm not familiar enough with Klein, but if you're using a strong cryptographic hash function, then correlations in the input should not translate to any correlation in the output. So using incremental input vs random numbers shouldn't make any difference, at least in theory.

Of course any weakness in the hashing function may mean that this is not the case.

However, if you are not the only person searching then you want to avoid searching on places that many other people have searched through. You are less likely to find a better solution than the current best solution if you are searching through parts that have been extensively explored. Many people probably also starts the search incrementally starting with 1, which is a highly explored range, so you want to avoid increment from 1. You would want to start the search with a random number, then keep incrementing.


What use to automate incident response? I am now read about TheHive Project - open source incident response platform.
Today i asked developers about automatization of incidents, and find, that TheHive can't do this.

Main feature for me is automatization in the following directions:

get new data and add it from sources to incident (from AD, from
OSINT, from SSCM and etc)
write scripts to send mails to users by
such templates by API
add new tasks on firewalls or another

Does anybody can advise me something framework or open source project or some else?

TheHive has hooks to Cortex, which can you use for OSINT, but it does not have all of the integrations that you are asking for.

Active Directory, SCCM, and similar can be performed with WEF as Palantir maps out for you in their Github project.

AbuseHelper is the oft suggested platform to send email out. TheHive can definitely take email in, even Microsoft Exchange through Synapse.

For firewall automation from TheHive data, I’m not sure of your direction enough to make a specific recommendation. Typically, you will see one of 2 types of deny-level controls. The first is host isolation (aka host quarantine), such as seen using PowerShell here. The second would be using Suricata IPS rules that provide countermeasures to specific malicious logic, much more open-ended compared to a domain or IP block.

My thinking here is that instead of blocking everyone from accessing what could be a false positive, just block the single laptop that is reaching out to C2 or being social media / cloud cred phished or whatnot. If you have a firewall that can be configured for a list, then use blackbook or similar project as that list.


Aircrack-ng: Why deauth works When using aircrack to attack WPA, deauth packets are used to force a host to deauthenticate. But the machine sending these deauth packets is not even connected to the network. How possible is it that the AP accepts packets from a machine not connected to it? In other-wards, why would an AP or end host accepts de-authentication requests from arbitrary senders who are not even connected to the network?

AP accepts packets from a machine not connected to it
  from arbitrary senders

Normally, deauthentication [and other management] frames don't have to be encrypted (i.e. require an existing authenticated 'connection' between the AP and the client). Therefore, they can be spoofed.

The way to protect against this kind of attack is to use Management Frame Protection (check out http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/82196-mfp.html#climfp):

  Specifically, client MFP encrypts management frames sent between access points and CCXv5 clients so that both access points and clients can take preventive action and drop spoofed class 3 management frames (that is, management frames passed between an access point and a client that is authenticated and associated). Client MFP leverages the security mechanisms defined by IEEE 802.11i to protect these types of class 3 unicast management frames: disassociation, deauthentication, and QoS (WMM) action.

What are the legitimate uses for deauth frame?

In addition to just that, termination of the secure communication (e.g. 'Forget this network'), there are a few possible reasons specified by 802.11, like these (reason/description):

2 - Previous authentication no longer valid
3 - Station is leaving (or has left) IBSS or ESS
4 - Disassociated due to inactivity

(you can read more at, for example, https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes or  )

Why is it that Access Points do not implement these Management Frame Protection mechanisms?

It is available in many APs, but usually "Optional" by default, to prevent client connectivity issues. You can read more in this answer: 802.11w protected management frames - Wi-Fi

Personally, I think that it is not such a big deal, because (a) strong PSKs make bruteforcing long and non-so-effective, (b) you can just wait for a legitimate client to leave and come back to catch the handshake. I.e. it makes it harder to get in, but doesn't prevent the possibility.


Detecting the presence of wifi devices Is it possible, with a normal wifi adapter, to detect present wifi devices in the surrounding? Let's say, is it possible to detect an Iphone with wifi switched on in the range of my wifi adapter?

Perhaps it's possible to create a fake AP with an ESSID and encryption thats stored in the favorites list of the device that should be detected, but actually I am searching for a more generic way, without knowing the favorite networks.

Also, I remember I had found special hardware once for this purpose, but again, I am looking for a method where standard hardware can be utilized.

You will need a wireless nic that permits a 'monitor' mode, and that requires some special drivers and special nics.

Kismet's list of cards for Linux
tests on different cards
pineapple device (special device)
airpcap nic (specialized nic for Windows)

Once you get a card, you will need software to deal with the data and Kismet is the leader in this area right now.


Licensing system for client side code web application I have a client-side web application running on SharePoint Site Collection, each site collection has it's own unique id. I want to use a licensing process to lock the app to a site collection.

This is the challenge-response process I'm trying to implement:

User prompted to generate challenge code
challenge code is site_collection_id processed through some function
User emails me challenge code
I encrypt/hash challenge code with someting (RSA private key?)
The encrypted result is considered the license key which I send to user
User saves license key into the application

Validation Process:

On app load, retrieve license key
Decrypt/un-hash license key using something (RSA public key?)
The result is the challenge code the user had sent before
Compare the challenge code you've generated from the license to the one you'd get from the site to determine if they match

Does this make sense? The one thing I'm not sure about is the public/private key stuff and if there's a way to do this in JavaScript. From what I've read, I can't use RSA securely to encrypt with private key and decrypt with public. It's normally the opposite. So I'm looking for alternatives

Just to be clear, I need to store something in the application script that I can use to decrpyt the license but I'd be encrypting the challenge code either on a different site or server side

I know it's impossible to 100% secure client-side applications. I'm just looking for something to prevent someone from easily distributing the application

Your scheme is pretty close, i'd say. RSA in JavaScript is a pain in the ass, so look for a library that does it for you. This is my suggestion for your final scheme:

Client sends you the site id i
You sign that id with your private key p: S = RSA-SIGN(i, p) = i^d mod n
You send S back to the client in a file or in an e-mail
Client stores the license file
When the web app loads, download the file (S') and your public key o and do the math: S'' = RSA-VERIFY(S', o) = S'^e mod n. If S'' = S', the license is ok.

The RSA formulas in here are Textbook-RSA and cryptographically insecure. One might recover the private key. So make sure to use proper padding and hashing (keyword: PKCS7)

P.S.: As the TO said, this is not 100% secure. It cannot be since client-side code can be fully tampered with easily.

P.S.S.: I think an online form for steps 1 through 3 would be much better usability-wise than emailing that stuff around.


Spooky Suspicious Sign-In From My Town I just had a weird experience that I am trying to figure out. I received a suspicious sign-in notification from google on my gmail account. They had my correct password. This isn't that surprising, the password was old and probably breached and needed to be changed anyway.
The weird part is that the attempt came from my town, on a device listed as Windows NT. I don't own any Windows devices. And this isn't NYC or somewhere that could be a coincidence, this is a small city of about 100k people.
Unfortunately I didn't think to save the IP or other information that came with the notification and now it is gone, and the "last 10 sign-ins" page is overwritten with new activity.
This seems to imply that somebody in my town has my email/password and tried to log in with it. But I just moved to this town and I don't know anybody here! I don't know how anybody could have that information.
Does anybody have any insight here? This is creeping me out.

The most likely possibility is that your browser was mis-identifid as Windows NT for some reason. Google treats logins from the same device but a different browser as a new login, for security purposes, and alerts you. It's quite likely that this login was legitimate but just improperly identified.
Another potential is that some malicious app stole your Gmail login credentials, and used it to sign in with a spoofed user agent string.
Either way, I strongly suggest taking the following precautions:

Go to Device Activity and check what devices are logged in. Log out any that you aren't using any more, or don't recognise.
Go to Security Checkup and perform all the steps there. Particularly pay attention to third-party access, as many malicious apps will gain access to your gmail, add themselves as a third-party app with full access to your account, then delete the alert emails from your inbox. This gives them persistent access even if you change your password.
Start using a password manager. I recommend KeePass, but there are lots of options.
Perform similar checkups on any of your other accounts. A compromised email account means that an attacker can reset passwords on other stuff. If you've used this password elsewhere, make sure to change it on those services. Most social media sites have their own security checkup pages.
It's technically covered by a previous step, but I want to emphasise that you should enable 2FA. It's really important, particularly on things like Google accounts, Microsoft accounts, Apple accounts, anything with monetary value (banking, Steam, Amazon, etc.), and any social accounts (Facebook, Twitter, Reddit, Slack, Discord, etc.) that might be used by an attacker for spam. If you run any web hosting or domains, check over those accounts too and enable 2FA where supported.
Check HaveIBeenPwned to see if your email address appears in any password leaks. Chances are the answer is yes. Use this to think about where you might have reused passwords that were used in any of the compromised services.
Check your outbox and deleted emails on gmail. If your account was compromised it may have been used to phish people in your address list, or to send malware to people. Ask your friends to keep an eye out for anything strange coming from you online.


Why does my debit card have a stripe AND a chip? Recently I received a new debit card which has both a magnetic stripe and a chip (as did my previous card).

I know the magnetic stripe can be easily copied whereas the chip system hasn't been compromised (yet?). I suppose the stripe is still there for legacy purposes, even though in the last years I've not seen nor heard of a terminal or ATM that didn't accept chip payment.

As far as I am concerned, that's like buying a new fancy lock for your front door while leaving the back door unlocked. Is that analogy right, i.e. is a card with a stripe AND chip no more secure than a card with just a stripe? And if so, why would my bank allow such a security risk? Why not get rid of the stripe altogether?

Ps: If it matters, I live in the Netherlands.

EDIT: For clarity, I'm mostly concerned about the following scenario:

A thief skims an ATM (probably (?) chip payment), but can still get the stripe because the card goes into the ATM. Suppose he reads my PIN too. He then fabricates a new card and empties my bank account.

Details depend on bank, card type and country, so they vary quite a lot, but the generic model is the following:

The magnetic stripe contains, mostly, a computer-readable copy of the information embossed on the card: account number, holder name, expiration date.
The chip contains a secret key which is used to "sign" (not necessarily a true signature; often a MAC) transactions.
The chip knows the PIN code and refuses to work until the PIN code has been presented; it also locks itself if too many wrong PIN codes are presented.

When a payment terminal uses the magnetic strip, it must talk to the bank, establish a secure tunnel with the bank, send the PIN code entered by the user, and verify that the owner's account has enough money on it.

On the other hand, when a payment terminal uses the chip, the PIN code is sent to the chip only, and there is little need to talk to the bank at all. The whole transaction can be conducted offline. Of course, for big amounts, it is still a good idea to talk to the bank to know whether that much money exists on the buyer's account, but small transactions can be done efficiently with no network at all.

Thus, the magnetic stripe and the chip are used in two different ways, and having both does not mean that the security is lowered to the security of the weaker of the two. From the bank point of view, chips are better, because they are more efficient (no need to handle a network call) and harder to clone (statistics show a fraud rate divided by about 10). This is often translated into financial advantages granted to merchants who switch to chip-aware terminals.

There can be variants in all of the above. For instance, some card include in the magnetic stripe an encrypted version of the PIN code -- but it won't be verified in the payment terminal. Instead, the terminal will have to talk to a regional bunkerized server who knows the decryption key and can do the verification. For some other card types, it is pretty clear that the magnetic stripe does not know anything about the PIN code, e.g. the chip-less American Express cards (from a few years ago) where you could change your PIN code by phoning your bank.

In any case, all the security features of a debit or credit card are not meant to protect you. They protect the bank. From the point of view of the bank, you are the enemy (regardless of what they claim in their ads).


What's wrong with storing private keys in the cloud? I know this sounds like a dumb question, but whats wrong with it?  Assuming that all private data is encrypted (by the client) using PBE AES256, then is this scheme more vulerable than storing keys on your local computer?

Pros:

all of your devices (smartphone, laptop, camera?) have access to the same keys without having to copy them everywhere and protect multiple devices
assuming the key server is hosted by someone who knows security, the data should be more secure than your smartphone or laptop

Cons:

a single successful attack could take down millions of (encrypted) keys in one go (remote attack, malicious employee, etc)

My understanding of the current situation is that you keep your private keys encrypted on your local computer protected by a passphrase (*.JKS, *.BKS, secring.gpg, etc).  An attacker could write a trojan that uploads all of your private key files to a server under his control.  This has recently started happening with BitCoin wallet files, so it's plausible it could happen with key stores.  That would net the attacker many key stores in one go, the same as a successful attack on a key server, and, as far as I can tell, for approximately the same complexity.  Also, current key store files aren't providing any more protection from an attacker than AES256 would, since they all revolve around the user's passphrase.

It appears to me that the real weakpoint here is the user's passphrase and not necessarily where the keys are stored.  Am I wrong?  I know this isn't the ideal situation, but I'm comparing it to the current situation.

Anything which is encrypted with PBE (as in "Password Based Encryption") can be the subject of an offline dictionary attack (i.e.: the attacker tries potential passwords). This is a worry unless you have a super-strong password, which is not as easy as it can seem because you also have to remember it, and to type it regularly (if you note it down somewhere, it is not really super-strong). Shortcomings of not-so-strong passwords can be somewhat mitigated by using heavyweight Key Derivation Functions such as bcrypt.

"Strong enough" means "having an entropy of 128 bits or more" which means "the password generation scheme you used may have generated at least 2128 other distinct passwords" -- so we are not talking about 8 or 10 characters, rather 20 completely random characters, or a list of 10 randomly chosen "common words". Speaking of which, it is meaningless to insist on AES-256 in that situation: AES-128 will be already fine (i.e. the weakness will be the password, not the AES).

If you have a strong enough password, you can store in the cloud whatever confidential data you wish, encrypted relatively with this password, including private keys. You still have to trust the cloud manager for not losing your files, but, on average, data is safer in the cloud than in the entrails of an expensive mobile phone that you brandish when walking in the street (remember, mobile phones are stolen even more often than cars). Unless the cloud manager has a grudge against you, of course.


How to reject e-mails spoofing your own domain targeting your employees at Office365? One problem Office365 users deal with is that an external SMTP server can spoof the domain of an organization and send e-mails to the domain users; where the e-mails appear to be from employees of the organization. On the header the authentication results would look like this:

spf=none dmarc=none dkim=none (message not signed) (sender IP is x.x.x.x)

smtp.mailfrom=theSpammer.xx; YourOwnDomain.com;  YourOwnDomain.com;

header.from=YourOwnDomain.com;  action=none header.d=none;

When the authentication values (e.g.,SPF) are not set, we cannot reject the e-mail. The From can be set to anyone at the organization, but the Reply-To and Return-Path can be set to the spammers choice to keep communicating with the scam victim at the target organization.

Does anyone have a solid solution to prevent the spammer and phishers sending e-mails that spoof the organization domain to send e-mails to the employees on that domain?

There is a recommendation here: https://community.office365.com/en-us/f/148/t/239589 that suggest creating a transport rule that filters e-mails originating from outside of organization while the sender's domain is the organization's domain. Has anyone used that successfully?

You should modify your DNS settings to set up SPF for your domain, so email messages sent from an outside IP address are rejected. By the way, the recommendation you link to in your post aims to achieve the same result.

That would be the more effective technique. Failing to do so, your best bet would be to digitally sign all exchanged inter-domain emails and/or train your users, but I understand these are not always viable options.


Generating request-specific token for an API We have an API openly accessible through a data visualization on a website and an app. We'd like to make the life of potential data scrapers a bit more difficult.

First thing we did was to add some throttling, but in our case the line between legit and malicious request rate can be blurry. It also doesn't keep scrapers from taking their time.

It's currently easy to see how our requests are built and create new ones, so we thought of making this more difficult by generating some kind of hash using chosen values (request parameters, current time, value in cookie, etc.) on the client side and checking it server side. The code generating the token would naturally need to be obfuscated on the client side.

So the question is, how useful can such a protection be? It appears to come down to how much we can obfuscate the token generation. How efficient is this, particularly in javascript?

Not terribly useful I think.  The attacker doesn't even have to understand your obfuscation - if they have access to the routines (I assume they do since its on the client) the attacker can just steal your code and run the same parameters through to create their hash.

If the server serves up previous pages that this is requested from, then you can add a one time token/nonce (a bit like a CSRF token) to the API.  This would make the subsequent request pretty much impossible to replicate without requesting the previous page first and getting their own token.

But even with this strategy, a scraper could always go back to an entry point page/URL and play through the sequence of requests as if they were a normal user.  This is likely to be a valid attack no matter what obfuscation you use since it's going to be indistinguishable from a valid user.


How do I control multiply-nested embedding of my iframe? Domain example1.com embeds my iframe.

Domain example2.com embeds an iframe served from example1.com.

I would set X-Frame-Options: ALLOW FROM *.example1.com as well as  Content-Security-Policy with frame-ancestors.

But then the browser does not allow showing the iframe content, because the window's domain is example2.com  which  does not equal example1.com.

How can I require whitelisting for the embedder (example1.com) and also for the embedder's embedder (example2.com)?

CSP frame-ancestors already does what you want.

Content-Security-Policy: frame-ancestors [...] checks the entire ancestor chain. If any parent document doesn't match the source whitelist, your document will not be loaded.

If your chain is top(child(grandchild)), this policy for grandchild would pass:

Content-Security-Policy: frame-ancestors top child

But none of these:

 Content-Security-Policy: frame-ancestors top
 Content-Security-Policy: frame-ancestors child
 Content-Security-Policy: frame-ancestors 'none'

X-Frame-Options: allow-from [...] only checks a single ancestor. The de-facto implementation in most browsers is that it checks the top origin but no origins in between.

If your chain is top(child(grandchild)), this directive for grandchild would work:

X-Frame-Options: allow-from http://top/

But none of these:

X-Frame-Options: allow-from http://child/
X-Frame-Options: sameorigin
X-Frame-Options: deny

The W3C CSP2 specification also explains the difference:

  7.7.1. Relation to X-Frame-Options

  This directive is similar to the X-Frame-Options header that several user agents have implemented. The 'none' source expression is roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN, and so on. The major difference is that many user agents implement SAMEORIGIN such that it only matches against the top-level document’s location. This directive checks each ancestor. If any ancestor doesn’t match, the load is cancelled. [RFC7034]

(Source)


On the Use of Deltas in Linux Entropy Estimators Recently, I've become interested in applied cryptography and stumbled upon a link explaining how Linux estimates entropy.

At some point, we're told that entropy estimation is based on first, second and third differences of the timestamps of certain system events. Fair enough. What I didn't understand was the intuition behind this, explained in the link as follows:

  This use of deltas is approximately the same as attempting to fit an n
  degree polynomial to the previous n+1 points, then looking to see how far
  the new point is from the best prediction based on the previous n points.
  The minimum of the deltas is used, which has the effect of taking the best fit of a 0th, 1st or 2nd degree polynomial, and using that one.

To clarify, here's what (I think) I've understood. Taking the example of mouse events in the link:

Mouse event times       1004   1012    1024    1025    1030    1041

1st differences              8      12       1       5      11

2nd differences                  4       11      4       6

3rd differences                      7       7       2

Fit an n degree polynomial to the previous n+1 points: I guess that would be taking the (i+1)-th diff, which are the 1st diffs of the i-th diffs. These could be used to predict the next values of the i-th diff, hence the 'fitting'. E.g. the 1st diff explains how consecutive values of the mouse event line (0th diff) change.

How far the new point is from the best prediction based on the previous n points: I guess this is given by the (i+2)-th diff? E.g. after the last mouse event time, 1041, the 2nd diff is 6, which is how far 1041 (the new point) is from 1035 (the best prediction). The prediction is obtained by taking the previous 0th diff value, 1030, added to the previous 1st diff value, 5.

Use of minimum delta: My best guess is that the entropy estimator chooses minimum value, because it is the best fit for the (i-1)-th diff (or (i-1)-th degree polynomial). I think I understand how this method picks the best fit, but I really didn't get the 'why' though.

My doubts/questions are:

I may be overlooking something obvious, but I still don't see the relation between my idea of n degree polynomial fitting (e.g. polynomial regression using a least squares method).
What's the actual rationale behind choosing the minimum delta? Why does it provide a good measure of how unexpected the next data point is? Is it because the minimum delta is the most conservative?

The estimator uses minimum third delta because the degree of the fitted polynomial of it is the entropy of the dataset. In the first example, the minimum delta was 2, its base 2 log is 1, therefore the data overall added 1 bit of entropy. Why the minimum delta? It is because using it allows to represent the entropy (in other words, unpredictability) of the entire dataset as a one-digit number. If you look at the entropy measurements in the first two examples (1 and 2 bits), you can see that they translate to 1st delta values of about 10 and 100, respectively. Accordingly, entropy of 3 would mean 1st deltas of about 1,000, 4 - 10,000, and so forth. In summary, in our delta representation we went from multiple to single digits by using the polynomial degree of the minimum third delta.


What does Blue Coat Unified Agent application do? I've experienced a crash of the Blue Coat Unified Agent tray application on my business laptop.

I was wondering what is the exact purpose of this software, and how is it supposed to help me or the company?

I know it provides Web security to remote users, but this doesn't tell me anything.

The BlueCoat Unified Agent has been built to provide security on the cloud. The Unified Agent client monitors the Internet Breakout IP being used by the user and switches from Active to Passive mode or vice versa depending on the company policy.

For example a company might have on-premise proxy servers. Therefore when the client uses the laptop inside the company network perimeter, the client falls into passive mode and lets the on-premise proxy servers handle the "washing" of the Internet traffic.

However if the client goes at home, or a hotel or any other place with a public Internet breakout IP which is not defined as a Corporate Internet IP by that company, the client will immediately switch to 'Active' state. That means that the client establishes an encrypted IPSec tunnel towards the nearest BlueCoat ThreatPulse data center and a proxy cloud server does all the security traffic "checking" on the cloud. Companies can sync their on-prem proxies to have the exact policy on the cloud but that is optional.

Additionally, companies that use the Unificed Agent can also define subnets / IP Addresses / URLs which are like an exception for the unified agent and that traffic goes direct to the destination without utilizing the IPSec tunnel (Split Tunnelling).  The above environment is also known as Hybrid (utilizes both on-prem and cloud proxies)

Moreover you can have a pure cloud environment. A lot of companies do not have on-premise proxies and they use the Unified Agent both inside and outside the Company Network perimeter.All those are possible setups of the Unified Agent (plus many more of course).

The key advantage of the Unified Agent is that it provides extra security layers. When a client makes a request, it will go to the Cloud Proxy, the proxy will check if the content should be obtained based on the company URL policy (i.e. the company could be blocking porn, etc.). If it is OK, it will obtain the content and AV scan it using AV engines on the cloud from 3rd party vendors like Kaspersky, TrendMicro, Symantec etc. It will also optionally send the obtained data to a sandboxing environment if the file signatures are unknown. If everything is OK, it will deliver the content to the end-point client.

Back to your question, a lot could cause crashing of the actual application. In any case you should check with IT support of your company. You can also check the Windows logs as it will have application logs for the Unified Agent. Also the Unified Agent offers a "tracing" functionality if the crashing happens while you are visiting specific URLs, etc.


Are memcpy() based race conditions exploitable for causing remote code execution? Let’s say I have the following pseudocode in the trusted part of a sandbox which prevent untrusted code calling mprotect() and mmap() and ptrace() directly (mutext isn’t accessible from sandboxed memory)…

//src and dest are user controlled but must be valid.
TrustedPart_for_safe_jit(void * mutext, uint8_t *src,uint8_t *dest, uint32_t size) // in the current case, *dest targets a PROT_NONE memory region
{
    MutexLock(mutext);
    ValidateOpcodesOrCrash(src,size); // uses calls to mmap on size internally. Contains many different loops and use several 10k thousands lines of codes in the trusted part of the sandbox : this is the longest part. Please also note that src is write protected while being in this function.
    unwriteprotect(dest,size); // calls many sandbox’s internal functions

    SafeMemcpy(src,dest,size); // THIS IS the function which contains the race condition

    asm("mfence");
    unEXECprotect(dest,size); // involve write protecting as well as allowing reading
    MutexUnlock(mutext);
}

SafeMemcpy(uint8_t *src,uint8_t *dest, uint32_t size) // the data to be copied cannot exceed 128Mb
{
    if(!CheckUserTargetPointToValidMemroyRange(dest,size) {
        uint8_t *src_ptr=src;
        uint8_t *dest_ptr=dest;
        uint8_t *end_ptr=des+size;
        while (dest_ptr < end_ptr) { // that loop should execute very fast
            *(uint32_t *) dest_ptr = *(uint32_t *) src_ptr;
            dest_ptr += 4;
            src_ptr += 4;
        }
    }
}

That part is responsible for allowing untrusted code to use ᴊɪᴛ compilation.
The point is untrusted thread aren’t suspended.

As you know, when 2 threads use memcpy() with the same destination, they generate random data. In that case, such data could potentially contains instructions like int 0x80, thus allowing to escape the sandbox.

Things I thought to so far :

Write data to a file and read it with the read system call through the sandbox. If the memory is still write protected the program doesn’t crash. This would involve looping and even if the data to be copied can be 128Mb large I’m not sure it would works because of syscall overhead.
An Alternative would be to create code several times and try reading with several timing, but I have no idea on how to select the initial timing window.
Use futex… But I couldn’t found if futex can be used to check the value of non allocated memory. I’m also unsure if the thread could wake up before memory become write protected.

So, is it possible to plan the timing window for memcpy race conditions ?

Based on what I see here, you can modify *src after ValidateOpcodesOrCrash finished checking that part of the memory but before SafeMemcpy starts.

I don't know how ValidateOpcodesOrCrash is implemented, but presuming that it simply loops through [src,src+size] and look for illegal instructions, then you can call with a fairly TrustedPart_for_safe_jit large size, busy wait for a few hundreds of CPU cycles, and then start overwriting *src that ValidateOpcodesOrCrash likely had finished checking. If ValidateOpcodesOrCrash does something more complicated, you can figure out what sequence of instructions will be the fastest and slowest for ValidateOpcodesOrCrash to check, put the fastest at the front and, a whole lot of the slowest instructions all up to the end. You probably won't need to wait for ValidateOpcodesOrCrash to complete before you start overwriting src.


Should a password generator validate its output against a dictionary? If I were to design a password generator, is it best to leave it truly random or validate its output to avoid certain passwords?

For example if my password generator was truly random, it's possible its output could be "password".

Where do you draw the line? Should it just scan for common passwords, or ensure nothing in the entire string matches a known word? E.g. skipping "fg3~nfpasswordh&tr" because it contains "password".

Does doing this reduce the security of my password generator because the possibility space is reduced?

When creating a password generator, use a cryptographically secure pseudo-random number generator (CSPRNG) and trust in the random properties of that system.

Rather than checking if a randomly generated password contains a substring that humans might recognize as a word, instead check that the entire password has not been part of a data breach.

The current biggest threat to passwords are offline attacks against data dumps.  Passwords should be stored using a key stretching algorithm, such as PBKDF2, bcrypt, scrypt, or Argon2, which makes it impossible to pre-build lookup tables and greatly increase the time that it takes to attack the passwords.

Additionally, these key stretching algorithms have an avalanche effect: A minor change in any of the inputs will make a huge difference in the output. (Caveat: With an infinite input space and a finite output space, there will be collisions.)  Cryptographic hashing algorithms also have this feature.  Thus, attackers can not tell how close they're getting to cracking your password, like they can in movies.

Thus, unless you've somehow told your attackers that password contains the word 'password', then it doesn't matter if there are human readable words that happen to appear in the middle of your generated password.

The current largest threat is from attackers that use dictionary attacks based on previously leaked passwords, because they know that users will reuse passwords, and will use known weak passwords in throwaway accounts.  The way to mitigate this, according to the NIST standards, is to check the whole of the password against a list of known bad passwords, such as dictionary words, expected patterns, and compromised passwords.

The NIST standard puts the onus of keeping users from using known bad passwords on the site owners, but there is nothing preventing your generator from using a service such as the Pwned Passwords API in the astronomically unlikely (but technically possible) event that your generator using a CSPRNG produces a password that has been leaked elsewhere.


Postgres password hash crack I installed the lastest version of PostgreSQL (13.2) to understand it better and I used the command SELECT usename, passwd from pg_shadow; to extract the hash with the default username postgres but I could not find any documantation of how to crack the password hash using john or hashcat so how can I do that ?
the hash example which is 1234
SCRAM-SHA-256$4096:bPlu66YYvUgvDwY31jQZTA==$ZbSxNzZQqdtLi+fcj15pg7ywEg5mO3xNOVfZJ+/2n0Q=:9ll3Le0+81qTnFwonM4ROCzeTjCRizYdm3ZO5yu/wcE=

You need to use a crack method that is designed for SCRAM-SHA-256. If jtr or hashcat do not have this (and it looks like they don't at this point in time), then you cannot use those tools.
Hashcat is working on this for -m 24200. You might be able to find a dev version that includes this.


ISO 27001 and copying code from stackoverflow So ever since we got certified, every time some code from stackoverflow is shown the ISO 27001 argument comes up "we can't copy code".

As a dev, I have to say not allowing code form stackoverflow is insane and nobody listens to that anyway because stackoverflow is literally for solving coding issues.

What's your take as a professional on this? How far is it permitted to copy code from stackoverflow?

Can we copy when we give credit? Do I put a link over each code snippet I copied?

Thanks for the help, in my company everyone and their aunt have their own interpretation of this and the result is, bosses are too scared so the official order is not to allow it.

Edit: We don't use any external repositories. Framework is bought, libraries are either directly from companies (Like Oracle DB library) or built ourself.

Edit 2: For example, I'd copy that piece of code, change some things around so it fits the actual use case, change the name so it fits, and put a link above it:
https://stackoverflow.com/a/2001462/4364057

I can hardly imagine an example or direct copy-paste from SO. I do see SO as a nice source for high quality code samples, and I have often used portions of code from SO answers, but then I have always slightly modified this code so that it smoothly integrates into mine: change variable names or formatting so that it respects my own coding standards, remove parts not relevant for my use case, add others. So it now becomes my code.

What is interesting in SO codes is the patterns, the implementation ways, and the comments around the code. It makes sense that code only answers are not well received. So blindly copying code is a poor usage of SO and hopefully is forbidden by your organization rules.


If I know a currently working exploit to spoof SMS on a major carrier, what should I do? This currently works on all iPhones and one known android phone as of today, a formal complaint has been filed with the carrier and the FCC. I doubt they will do anything about it though since this is SMS protocol working as intended, and any particular spoofing technique is not (from what I can tell) interesting, and not a valid bug report.

I also am not a security expert by any means and would like any references to research materials to help me write a formal report on how this is actually working, but I have very little expertise and kind of just stumbled on this. Any known suite of tools also to help me do this would be great.

The exploit is purely software in nature, there is no use of hardware except the phone obviously, I have a feeling that it may be an issue with the carriers email -> SMS gateway, which to me is something they could probably fix.

Make a demonstration video.

I have found that demonstration videos are an incredibly powerful way to communicate security issues, capturing the attention of managers who would otherwise dismiss this as "geeks talking geek".

Try to make the video as real life as possible. Include an example that is not just "oh look, this shouldn't happen" but actually gives a plausible real world scenario where this would be a serious issue.

Do not include technical detail in the video. If there's a technical step, just show someone running some commands on a computer - maybe even blur the screen to hide the commands. The video is to show WHAT can happen, not HOW it happens. This also means the video is less sensitive, as it doesn't contain technical details of the vulnerability.

If it is only some carriers that are vulnerable, include an example of attempting the same attack on a non-vulnerable carrier - to show that it doesn't succeed.

Share the video with the carrier privately at first, and tell them that if you don't get an adequate and timely response you will share the video more widely.

Here is an example of myself and a colleague in a demonstration video.


How to implement “forgot password” functionality? For my project I need a "forgot password" functionality.

I am not quite sure how to implement this kind of functionality yet so I was hoping to find some "best practice" on the internet but couldn't find anything useful that treats every important aspect of this quite common feature.

My own thoughts about this are rather straight forward:

If a user wanted to change his password I could create a unique token uniqueTokenForTheUser attached to a "change password request" which would be essentially the identifier for my backend to tell if it was the right user who sent the request.

So for example I'd generate/send an email to user@example.com with a link

http://www.example.com/changePassword?token=uniqueTokenForTheUser

uniqueTokenForTheUser would be stored in a table that gets checked by a thread in a certain interval and removes the record once the token is expired in case the user did not actually change his password.

Although this sounds rather straightforward to me, I wanted to double-check if there were any "best practices" out there e.g. when it comes to generation and deletion of that particular token.

Any suggestions or references to articles/tutorials are welcome!

Additional links suggested by comments:

The definitive guide to form-based website authentication (Thanks to Krumia)

Use HTTPS only for this, and then we'll get onto details of implementation.

First of all you're going to want to protect against user enumeration.

That is, don't reveal in the page whether the user exists or not. This should only be disclosed in the email itself.

Secondly you will want to avoid referrer leakage. Ensure no external links or external resources are present on your target link. One way to mitigate this is to redirect after the initial link is followed so that the token is no longer in the query string. Be aware that if something goes wrong (e.g. your database is briefly down), and a standard error template is shown, then this may cause the token to be leaked should it contain any external references.

Generate a token with 128bits of entropy with a CSPRNG. Store this server-side using SHA-2 to prevent any data leakage vulnerabilities on your reset table from allowing an attacker to reset passwords. Note that salt is not needed. Expire these tokens after a short time (e.g. a few hours).

As well as providing the non-hashed token to the user in the email link, give the option for the user to navigate to the page manually and then paste in the token value. This can prevent query string values from being logged in browser history, and within any proxy and server logs by default.

Optionally you may want to make sure that the session identifier for the session that initiated the password reset is the one that followed the link. This can help protect an account where the attacker has access to the user's email (e.g. setting up a quick forward all rule with limited access to the email account). However, all this really does is prevent an attacker from opportunistically following a user requested reset - the attacker could still request their own reset token for the victim should they want to target your particular site.

Once the password has been reset to one of the user's choice, you will need to expire the token and send the user an email to let them know this has happened just in case an attacker has somehow managed to reset their password (without necessarily having control of their mail account) - defence in depth. You should also rotate the current session identifier and expire any others for this user account.
This negates the need of the user having to log in again, whilst also clearing any sessions ridden by an attacker, although some users like to have the site log them out so they get a comfort blanket of confirmation that their password has actually been reset. Redirecting to the login page also gives some password managers the chance to save the login URL and the new password, although many already detect the new password from the reset page.

You may also wish to consider other out of band options for the reset mechanism and the change notifications. For example, by SMS or mobile phone alerts.


How does AVG insert its signature into Gmail emails? I just sent an email from gmail loaded in my Chrome web browser. Also on the Windows 7 computer is AVG "anti-virus". Turns out AVG somehow managed to insert a signature into the email I sent out.

This seems like a huge breach of security, in either chrome, Gmail, or Windows 7, as I never added any AVG extensions to chrome.

How was AVG able to interact with Chrome (or Gmail) to inject the signature into my email.

Like many other antivirus AVG is doing SSL interception, i.e. it puts itself as a man in the middle into the connection between browser and server. This way it can both read and also modify the traffic and can also add this mail signature.

The browser trusts this active man in the middle since the CA AVG uses to create new certificates is added as trusted to the system/browser. See also Why is 'avast! Web/Mail Shield Root' listed as CA for google.com?.


Why is Firewire a bigger threat than USB? This question notes that a person briefly connected an Android device to an Apple computer via USB, and one comment indicates that it would "quite possibly" be a risk:

  In theory, yes, in practice, probably not. If it had been a Firewire device, quite possibly. – Matthew

Why is Firewire a bigger threat than USB? How can connecting  a Firewire device to a machine be a security risk?

I am a PC user and don't know anything about Firewire.

Firewire and also Thunderbolt provide direct access to the OS memory, thus bypassing the operating system. See Wikipedia: DMA attack for more details on the possible attacks.

USB does not provide this kind of direct access. But it has other problems like the ability to unexpectedly emulate devices like a keyboard, see BadUSB.


When is it safe to use a web based FTP client? Is it safe to use a web based FTP client? If so, when? What should I watch out for?

Probably not - if you enter your FTP details into a website, you have no idea where they could end up. Furthermore, FTP is insecure anyway - any data transferred over it (including your login details) is viewable in transit in clear text. This could be between the web service and the FTP server, even if the connection to the web service uses HTTPS. In this case, you can't see what is going on, since you personally have no access to that connection.

Ideally, use SFTP, directly from your machine, or over a VPN - in either case, everything beyond the initial connection is encrypted, including credentials and data.


Does password strength matter when using a YubiKey? I'm considering buying a YubiKey. I already use a password manager which can generate strong passwords, but I wonder if there's even a point with the YubiKey. I guess it just makes one extra step...but if you can't log in without my YubiKey then does it matter? I'm not really worried about someone stealing the YubiKey IRL.

Am I missing something?

Multi-factor authentication is based on the idea that if one authentication factor fails, you have others to protect you. If someone tricks you into giving up something you know (ex: a password), they will be thwarted by something they don’t have (ex: a hardware token generator).

If you used a good password and were sure that no one could steal (or trick you into giving up) your password, then having a hardware token generator doesn’t really make sense. If you were sure that no one could steal your hardware token generator, then having a password doesn’t make sense. But this defeats the idea of multi-factor authentication.

So to answer your question, if you are very confident that your Yubikey won’t be stolen or cloned, then having a strong password doesn’t offer a huge benefit. But you also limit the benefits of multi-factor authentication if your device does get stolen.

This answer also assumes that websites implement all of the authentication factors correctly. This isn’t always the case since some websites such as Apple don’t require the second factor for all of their services. Historically some services like “Find my iPhone” required only a password and not your second factor even if it was enabled on your account (this may still be the case, but I haven’t checked).


Are there any known collisions of a "long" (64 bit) OpenPGP key ID? We know that the "short" 32 bit OpenPGP key IDs can be easily brute-forced and the recommendation is to use the "long" 64 bit IDs or full 160 bit SHA1 fingerprint.  However I am concerned that the "long" key IDs may also be brute-forceable in the not-so-distant future.

Given that a collision would generally be a precursor to a successful preimage attack, are there any known examples of a collision being found for a long key ID?

OpenPGP IDs are portions of the SHA-1 fingerprint, as defined in the standard. A short key ID is the last 32 bits, and the long key ID is the last 64 bits. A collision typically takes an average of 2n/2 operations, where n is the size of the hash in bits. Generating collisions for short IDs and long IDs is trivial, requiring an average of 216 and 232 operations, respectively. A collision in this case is defined as creating two differing hash inputs which have identical digests. It is actually even possible to collide the full SHA-1 fingerprint, as Google has shown. Colliding a full OpenPGP fingerprint requires nothing more than colliding a single SHA-1 hash. This is difficult, but possible with sufficient computing power.

Creating a preimage is different. Unlike a collision, a preimage attack requires creating an input that matches a specific hash digest. The attacker does not get to provide both inputs, only one, making it a much more difficult attack. Unlike a collision attack, a preimage attack requires a full 2n operations for a hash of size n. Because of this, creating a preimage for a short ID requires only 232 operations, which is downright trivial. Doing the same for a long ID requires 264 operations, which is not easy, but far from impossible. Doing the same with the full 160-bit fingerprint is simply impossible with current technology.

In summary:

+-------------+-----------+------------+
|             | Collision |  Preimage  |
+-------------+-----------+------------+
| Short ID    |  Trivial  |    Easy    |
+-------------+-----------+------------+
| Long ID     |   Easy    |    Hard    |
+-------------+-----------+------------+
| Fingerprint |   Hard    | Impossible |
+-------------+-----------+------------+