Can ROM checksum checker reliably defend against non-physical tampering/hacking of a voting machine? Every time there are elections in USA, questions of the security vulnerabilities and hacking/tampering with voting machines are raised (I'm sure that it's not US-only phenomenon, either).

Obviously, preventing hardware level hacks is a whole different kettle of fish, but if we assume that the machine is physically secure - if for no other reason, because there are just so many, all over entire USA, so it's nearly impossible to tamper with meaningful enough amount even only counting swing states), would the following approach be a reasonably reliable way to prevent non-physical tampering/hacking of a voting machine?

Have a real ROM (non-writeable) storing the checking code
Checking code verifies that the voting machine software is valid (presumably, by computing checksum, and verifying the checksum against known valid values - for example, stored on a website of Federal election office).

Use public key encryption for ensuring that the check-sums retrieved are indeed sourced correctly (using federal election office's public key).

If checksum fails, use separate hardware NOT controlled by the rest of the electronics in voting machine, to at least signal malfunction, or even lock out voting functionality.

Since the checking code is 100% in ROM, it would require physical access to the machine to mess with (and if it's sufficiently well protected, e.g. within a welded compartment, would be extra hard to screw with).

UPDATE: just to be clear, the assumptions here are:

Any attack is external to the machine's vendor, and therefore, the software written for it by the vendor does exactly what it's supposed to do barring adequately explained by stupidity bugs.

There are no clever trojans in the code, there is no attack vector in the compiler used by the vendor. The question's context is defending against an attack by a 3rd party on a perfectly valid functioning machine.

Reasons: because the context in which I asked the question was 3rd party attacks in real life (and not baked in trojans). Also, because otherwise, the question becomes trivial to answer and uninteresting. Of course you can suborn the vendor with enough resources, duh.
You can also assume you can trust the checksum signatures on the federal website - why that is the case is irrelevant, but heck, it's as simple as having interns from every party of interest sitting there all election day with printout of original checksum and verifying that the website still matches the printout.
There were objections raised to assumption that physical security through "obscurity" (or sheer volume) is effective-enough because there are only very few swing precincts. This is actually a valid assumption to make.

Reason: in practical US politics, given the polling margin of error (witness 2016 elections), knowing what the swing states/precincts would be is near impossible. Never mind that in wider-change elections like 2008 or 2016 or 1992, the amount of machines you need to tamper with to actually affect the outcome of electoral college (instead of slightly shift its vote margin) requires TONS of states/precincts to change. 2000 election with Florida's specific precincts was an outlier, not a rule - and even in that election, predicting that Florida would be a swing state with those specific precincts was not easy.

There are a lot of assumptions in your description, and not all of them are valid.

Assuming physical security is a problem.  Election officials have access to the machines, and presumably have the keys to the locked innards.  Hidden physical tampering is always possible.  Someone could hide a Raspberry Pi inside the cabinet that replaces the main machine, and it could respond in all the right ways.  Even the election officials would not know the difference.

Assuming that there's safety in numbers is a huge problem.  I can't find the source right now, but a while back I read a paper on Schneier's blog that an attacker doesn't have to corrupt an entire swing state, but only a few swing precincts within one or two swing districts within the state.  Predicting which precincts to corrupt is entirely possible.  Theoretically, the outcome of the entire presidential election could be altered by tampering with only a few dozen voting machines across the country.

Assuming there is "an" application to be checked is a problem.  The machine has an operating system, a user interface, a ballot reader, a tally recorder, etc.  The checksum would have to represent the entirety of the machine and all of its peripherals, not just a single program.

You're describing what is similar to the UEFI Secure Boot process.  Microsoft, Intel, and others have had problems trying to get this to actually be an effective way to secure a machine (a Blackhat presentation showed ways around it.)  Without a specific working implementation and years of analysis and attack, it's impossible to pronounce "X is secure"; even with a working implementation, I know of nobody that would stake their professional security reputation on such a pronouncement for voting machines.


Windows Kerberos Pre-Auth Failed (4771) Is there an easy way to distinguish 4771 events from a real attack perspective vs. someone having a stale session with an old password?

If you don't get logs from all endpoints and rely on Domain Controllers, you have to key off of 4771 and 4625 for failures, where 4771 is the Kerberos events from the domain joined computers to the DCs.

It's nice having visibility across the endpoints without getting logs from everything but for these 4771 events, most of the alerts I see are just stale sessions and non-security events. I don't see any sub code or item to key off of for stale/old password vs. real attack.

Most of the time these events are noisy in a large user environment with a password change policy. Most of the time this happens when an account's password is expired and it is tied with some application/service/task which keeps trying login again and again.

If you have SIEM or log management solution, you can create a rule to ignore 4771 events for account's password was recently reset 4723/4724 (say in the last 24hrs).


CDN vs server-level GeoIP Suppose a website is set up so that only IPs from country X are allowed read/write access. This server goes through a CDN such as Cloudflare.
Because the GeoIP read block is at server level, it never actually works because Cloudflare will always cache from an IP in country X and broadcast worldwide so anyone outside of country X will still be able to read the version that was cached by Cloudflare locally.
What vulnerabilities remain open with this setup on the write side?

Cloudflare is essentially a reverse proxy which might also cache content. If the content is then actually served from the cache or if the request is passed through the origin server can be influenced by the server itself through the use of standard Cache-Control HTTP headers. Thus, if the server wants to control access to specific content but still allow other content to be cached just set Cache-Control appropriately.
Additionally the original client IP address can be passed through the server as a special HTTP header so that any geo-blocking can be done.

What vulnerabilities remain open with this setup on the write side?

When properly setup using above mechanisms only the usual risk of a CDN apply, in that the CDN can in theory read and modify any content in transit, even if https:// is in use.


Intercepting JSON responses on BurpSuite By default, Burp Suite is able to intercept the request from the page, but not getting the JSON response.
What rule should be added in the 'Intercept server responses' menu (in the 'Proxy > Options' tab) to be able to edit the JSON responses received from the server.

BurpSuite will not intercept server responses by default and display them to you.
To enable this functionality go to:
Proxy -> Options -> Intercept Server Responses
And make sure to check the box next to
Intercept responses based on the following rules
Then either select one of the displayed rules or add one like the highlighted one below:

Also make sure to enable Intercept in the Intecept-tab.


How safe are wifi enabled talking toys? There have been ads on the radio recently for a wifi enabled toy called Talkies, which are advertised as being able to communicate with app enabled phones, with a "trusted circle" that other phones can be added to.

(Obligatory photo of a cute wifi enabled critter)

Especially considering the Krack vulnerability, and the known process of "grooming" a child that a sexual or other predator goes through to gain their trust and exploit them (Here is a story about how Snapchat was used), is this a toy that I should steer away from for my child? (3 years old currently)

Be very, very careful. It's not KRACK that is the problem, it is a lax attitude to security and privacy in general. So called "smart" consumer products can often be hijacked, accessed from the internet, or monitored. As a customer, it is hard to know if any specific product is safe or not.
The Norwegian Consumer Council has been on the case for a while, and produced a few horror stories. From a report, aptly titled #ToyFail, on three "smart" dolls:

When scrutinizing the terms of use and privacy policies of the connected toys, the NCC found a general disconcerting lack of regard to basic consumer and privacy rights. [...]
Furthermore, the terms are generally vague about data retention, and reserve the right to terminate the service at any time without sufficient reason. Additionally, two of the toys transfer personal information to a commercial third party, who reserves the right to use this information for practically any purpose, unrelated to the functionality of toys themselves.

[I]t was discovered that two of the toys have practically no embedded
security. This means that anyone may gain access to the microphone and speakers
within the toys, without requiring physical access to the products. This is a
serious security flaw, which should never have been present in the toys in the
first place.

And from an other of their reports, again aptly named #WatchOut, on "smart" watches for kids:

[T]wo of the devices have flaws which could allow a potential attacker to take control of the apps, thus gaining access to children’s real-time and historical location and personal details, as well as even enabling them to contact the children directly, all without the parents’ knowledge.
Additionally, several of the devices transmit personal data to servers located in North America and East Asia, in some cases without any encryption in place. One of the watches also functions as a listening device, allowing the parent or a stranger with some technical knowledge to audio monitor the surroundings of the child without any clear indication on the physical watch that this is taking place.

And the FBI agrees:

Smart toys and entertainment devices for children are increasingly incorporating technologies that learn and tailor their behaviours based on user interactions. These features could put the privacy and safety of children at risk due to the large amount of personal information that may be unwittingly disclosed.

So unless you have a real need (other than "this is cool") for these kinds of products, I would say that your best approach is to simply stay away from them.


How to determine if Windows 10 executable can connect to my network I'm considering use of a scanner driver I see on a website. I don't know the site or the owner so I'll be paranoid and assume that this Windows 10 exe is malicious. I can run the code in a throwaway VM. What I'd really like to know if there's code in the driver that might try to access my network. Monitoring the network while running the driver code is not good enough. That code might be benign for some period of time and then become malicious. So, I'm wondering if there is some tool that can read (disassemble) Windows 10 exe code and identify any code that tries to access the network.

You could always setup a firewall rule.  Open Windows Firewall, and select ADVANCED SETTINGS
Right-click on OUTBOUND RULE, select NEW RULE.
Select PROGRAM
enter the pull path the exe under THIS PROGRAM PATH
BLOCK THE CONNECTION
Apply to All 3 connection profiles (domain, private, public)
And give it a name... done!


Is it safe to plug my own USB drive into unknown pc? Is it widely known that in the opposite way (an unknown USB to safe pc) it could be really dangerous. But I can't find any info if is it dangerous to put a drive to other pc.

Case:

I have my USB drive with some unimportant data to print.
I put it into pc in copy point.
I print my stuff.
I take USB home and I format the disk.

By dangerous I mean: could my drive be infected in a way that cannot be repaired by format or even with more complicated "healing" process. In my case, I don't care about the data which is stored on that drive.

You said,

  I can't find any info if is it dangerous to put a drive to other pc

Before anyone tries to answer that, we need to know what you consider "dangerous" to mean.

If you're concerned about the contents of the files you've put on the drive (including any metadata that may be attached to them), you need to abandon this entire idea, because there's precious little you could do to ensure the safety of that data. The files should be considered compromised as soon as you plug the USB drive into the unknown PC. Software on that PC could easily copy, store, modify, or send your files anywhere.

If you're concerned about making the USB drive safe to use in the future, you need to at least be cautious. Taking that drive home and sticking it into an average personal computer would be dangerous, as the drive could have been infected by malware that could spread to your PC before you had a chance to format it. This malware could then potentially cause problems by corrupting or stealing personal information on your PC via a variety of methods.

Information Security professionals and enthusiasts commonly get around this risk by "nuking it from orbit" - either literally destroying the USB drive after using it, or accessing it from a system designed for dealing with infected media and then securely erasing it. Many times, these purpose-built systems are just a boot disk with a lightweight OS that's pre-loaded with security tools - but, crucially, has none of your personal information, and no access to your personal information.


What is the preferred way of using AWS (specifically S3) from mobile apps? Adding the AWS access key and secret key directly in app code is definitely not a good approach, primarily because the app resides on the users device (unlike server side code), and can be reverse engineered to get the credentials, which can then be misused.

Though I find this information everywhere, but am unable to find a definitive solution to this problem. What are my options? I read about the token vending machine architecture for temporary credentials, but I am not convinced that it is any better. If I can reverse engineer the secret key, then I can reverse engineer the code which requests for temporary credentials. And once I have a set of temporary credentials to access S3, I am as good as if I had the key. I can request the temporary credentials again and again, even if they expire pretty quickly. To summarize, if an app can do something, I can do the same as a malicious user. If anything, the TVM can be a bit better at management (rotating credentials, and changing key in case of breach, etc.). Please note we can put the same access restrictions on the secret key, as we plan to do in case of TVM temporary credentials.

Additionally, if Amazon doesn't want people to use the secret key directly in the App, why don't they block it in their SDK, and enforce TVM or the correct solution. If you will leave a path, people are going to use it. I read several articles like these, and wonder why?: http://blog.rajbala.com/post/81038397871/amazon-is-downloading-apps-from-google-play-and

Please help me understand if this is better, and whether there is a perfect (or may be good) solution available to this problem. I do get that TVM is more manageable (and much faster incident response once the credentials are compromised), but I am not convinced that it is more secure.

PS: This is mostly related to anonymous TVM, as users don't log in to our apps.

PS2: I am clear about the secure communication between TVM and app to get temp credentials, post the app registers. I am more concerned about what would prevent a malicious user from registering with a new UDID, and obtaining temporary credentials, and hence S3 access.

Have you considered signed URLs? If your app has authentication you can get the user to authenticate and then have your app create a custom signed S3 URL for the user. This then gets sent back and can be used directly from the application.
For authentication you can use something like AWS cognito. From this they get an auth token that you validate on your server to make sure the user is authenticated before you serve the signed URL.
For more info on Signed URLS
For more info on Cognito


CA storing root key in a bank safe deposit box. Concern? The CP/CPS of SwissSign Gold Certificate state that:

  5.1 "...Two identical clones of the SwissSign Gold CA keys are stored off
  line in Swiss bank safe deposit boxes."

They even put in their Why SwissSign page as their first "selling point":

  The «master key» for our certiﬁcates is stored safely at two Swiss
  banks

Is this common among CAs? Isn't a concern that the private key is printed somewhere? Shouldn't they be inside a HSM without a way to extract it?

With the keys for a certificate authority, there needs to be a balance between confidentiality (they need to ensure that the keys aren't disclosed without authorisation) and availability (they need not to lose the key entirely otherwise they can't use it to sign certificates).

If they stored their key in an HSM with not way to extract it, then there's a real risk that the HSM would drop the key, and at that point they would be in a bit of a bind in terms of ever issuing more certificates.

From what I've seen of CA handling splitting the key up and then storing it in physically safe locations, is very common practice.


What recommended precautions should one take when using internet provided by a Landlord? I am curious about what necessary steps/precautions one should take when dealing with a situation in which you have to use an internet connection provided by a landlord.

I assume you would at least want to replace the router and modem, and from what I've seen there is the Modem to the wall, to a box outside your house, to a box that connects multiple houses on the grid.  Any one of those could be tampered with, I would assume. I would think you would want to call the landlord's ISP to come out to the residence to make sure nothing had been tampered with as well?

I also have read a lot of people recommending VPNs when someone has to use "public wifi," but I'm not sure if a VPN is needed if we make sure that none of the hardware in the house/outside is tampered with?  I would assume VPN would be a smart idea regardless if we think the hardware is "safe," but I'm curious what others think?

I'm assuming the landlord could get a copy of what sites you visit, and what you do, from their ISP; however I am not sure if there are ways they could MITM the connection without tampering with their own devices?

I do believe VPNs would be the best (and easies solution) in this case, since all you need to do is get your own VPS server and VPN through it. You wouldn't even need to check modems/routers of your landlord.
If you don't want to VPN, just make sure all your connections are using SSL protocols (example: HTTPS, SFTP, SCP, SSH, etc), nowadays the chances of getting compromised by MITM attacks in SSL connections is low if you have all your applications updated and if you always check the site certificate.


Is IP whitelisting for webpage access secure enough? My organization utilizes Salesforce and Marketing Cloud. Very few people have access to MC, so I'm in the process of building MC hosted landing pages that will pull and display information such as marketing stats, pipeline stats, close rates, etc.

The purpose of using a landing page for this is so that I can give non-technical users access to an interface that graphs and displays relevant reports to them. (And saves me having to pull and Excel graph the info every x days).

Obviously, I don't want the general public to get access to these pages or data. The pages themselves will be marked as no-index no follow - but that doesn't fully stop the URL from potentially getting out into the open.

So, my next thought was to use the viewer's IP address against a list of approved ranges to decide whether or not to display data. Is this secure enough? What are some pitfalls?

By secure enough, I mean that I'm trying to guard against unknowing public access and competitive businesses that, most likely, would not assign anyone super technical to getting access to the page.

Please let me know if I can clarify anything further. Thanks!

First of all, make sure your Web site has all the necessary protection against typical XSS and CSRF threats, where a victim's browser, which sits on an IP address you've allowed to access the data, is tricked into revealing your data to a third-party.

Regarding IP ACL-based authentication in general, as long as it's only read access, you're probably fine with that. Nevertheless, it might be useful to know that under certain circumstances and given necessary preconditions, a motivated attacker can use BGP hijacking to impersonate your users for a relatively short period of time.

This method is somewhat easier to perform if an attacker is able to find out what source IP addresses are allowed to access the data; however, using methods similar to what have been discussed in this talk (video, slides, whitepaper), this requirement can be further lifted. (I'm the author of said whitepaper, so don't hesitate to ask for further clarification if you'd be willing to)

For most applications though, it's rather hypothetical, as it is unlikely that such a complex approach would be taken by an attacker, however, it heavily depends on how precious your data could be for a malicious person.

With respect to write access, IP whitelisting for TCP-based services in general should not be considered safe anymore, as a TCP connection can be successfully spoofed nowadays, given enough bandwidth and computational power on behalf of an attacker. However, using TLS is currently enough to mitigate this.

If only people from within your organization should ever be allowed to access the landing page, it might be a good idea to set up a proxy on the Intranet and to allow only Intranet addresses to access the data via that proxy. How the proxy authenticates on MC is more or less up to you. For an out-of-office access, a VPN could be set up, eliminating almost all the exposure to the general public (obviously except for browser-based attacks I've mentioned previously).


Why most of the Websites supports only Paypal for online transaction? Background : There are several electronic and email based online transaction system worldwide. For example, Paypal, MoneyBooker, Alert Pay and others.

My Question : Why most of the Websites supports only Paypal for online transaction?

This isn't a security question, however a quick answer:

It's cheaper than using a credit card broker. Paypal's fees are low, meaning more take-home for websites
The API is easy to use and well supported.


How do I allow websites to call my desktop app over HTTPS? I'm building a desktop app. I'd like websites to be able to communicate with the app over HTTPS. The general idea is that a website could run a JSONP call to https://127.0.0.1:8844 and send data to the desktop app.

The problem is that most newer browsers won't let you run a call in the background to a non-authority-recognized HTTPS site, so my self-signed cert is keeping browsers from calling my app.

The solution I thought of is to register local.myapp.com, point it to 127.0.0.1, and have a cert authority sign the cert for it. The kicker is the app is open-source, so I'll have to distribute the certificate/key to all the clients.

What are the security implications of having this information completely out in the open? Is there another way of allowing modern browsers to send data to a desktop app?

Security implications aside for a minute, it seems like this is either a bad idea or just plain won't work in many situations.

My solution, which sucks but isn't the end of the world, is to build browser extensions to communicate between the app and the browser. This way the extension can gather information about the current page, whether http or https, and send it via plaintext http to the desktop app via ajax.


Is this a good scheme for storing encrypted user credentials? We are building a service that manages multiple user accounts. For that reason, we need to store the credentials to a user's accounts using a symmetrical algorithm so they can be retrieved for the server to pull updates for the accounts. We however do not want to keep the keys in the database therefore here is the scheme we came up with:

User logs into our system using their password over a secure SSL connection. Each user account has a unique salt attached to their account and it is used to hash their password and verify against the database. Hashing function used for this process is bcrypt.
If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database.

I am no security expert therefore I will leave it to you guys to tear our scheme apart. Let the carnage begin.

You don't really describe this step very well:

  If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database.

Exactly how is that 128-bit key created? That should be a very slow process, otherwise you are providing a side-channel to brute-force user passwords. The way it would work is an attacker gets their hands on your database. Rather than try to brute force the bcrypt hashes, which would be very time consuming, they get to work on the encrypted passwords. They simply brute-force the user password to get keys that appear to work (ie: the decrypted text looks like passwords, whatever that means). This will be a fast attack because encryption is fast.

You need to make the 128-bit key creation a slow process. The best way to do this is probably to use bcrypt. But, as you have probably figured out, you don't want to use the bcrypt value that you've stored in the DB for authentication as that would not be a safe way to store encryption keys. I suggest that you keep a second salt for each user. You then use that salt, plus their clear-text password, in a call to bcrypt to generate the 128-bit encryption key.

When a user changes passwords, you should either wipe or reencrypt all of the encrypted passwords. This is needed because users frequently change passwords when they are concerned that their password has been compromised. So you better wipe the data that was encrypted with the compromised password. Though this, of course, won't help if the attacker already got a copy of the database before the password change.

Another security measure you could add is to pepper (search for "pepper" in this answer) the encryption key. The pepper should be a truly random bit string (no, your cat's name doesn't qualify) that you store someplace else. That is, it is not in the database. Use of a pepper will prevent an attacker who gets both a copy of your database and a user's password, from decrypting the user's data as they will still need the pepper. Remember that a pepper is only as helpful as it is secure. Putting it in your source repo is probably a bad idea.


Is it unsafe to have some users with passwords and some without? I'm working on an app where some accounts use passwordless authentication by email (using magic links) and some require a password to login. Is it okay to represent this rule in the account table by having a nullable password_digest? Would the application be more vulnerable to attack if and attacker knew which users have set a password and which ones haven't?

I don't see any problem with this, as long as there is no way for the user to generate a null password digest when attempting to log in.
Otherwise, magic links are no less secure than the access offered by the password reset feature on most sites already. You could even argue that having no passwords is more secure, since there is no longer a secret that can become compromised (assuming the email account is better protected).


Random people are coming to my home looking for their lost/stolen cellphones! Random people are coming to my home saying their lost/stolen cellphone is at my house!

The latest person to show up on my door step was at 9pm last night. He said that his "findmyiphone" sent him to my home. This has happened 2 times before and some people refuse to leave. I don't know what (if) the others used some kinda app to try to locate their phone.

A couple months ago a police officer came to my home saying they received a "911 hangup call" from my home. I've called Apple and they gave me some suggestions. I called my ISP and changed my network name and password, they had me also unplug the modem.

I am not computer savvy and have no clue what to do. I'm currently on the phone with my cell phone carrier and they seemed as lost as me. Any advice is appreciated.

This actually may be much simpler. I remember a few months back reading a story about a couple who had this happen on a nearly weekly occurrence. It turns out that one of these "find my phone" companies was lazy and had coded a spot to use as default if the GPS signal was lost. This spot happened to be on top of this couple's house.
Link:http://arstechnica.com/tech-policy/2016/01/find-my-phone-apps-mistakenly-bring-dozens-of-people-to-this-house-in-atlanta/

If/When this happens again(and it's the same app), I would ask the visitor's which app they used (as this keeps happening). Contact support at the whatever company it is and ask for them to review their code.


Is it safe to keep image of cleared check? I am developing an online banking site. Is it advisable to build a feature that allow user to download and save an image of their cleared checks on their computer? Is there any risk to user who download and save check image on their computer?

The chief risk in this is that the check has routing and account numbers on the image, so if someone were to intercept the download, they would have that information. Something like a MITM or hijacking your site to do XSS to download something besides the check image could be potentially harmful, but that's true of every site and not really specific to your question.

That being said, this risk of someone intercepting the download is relatively low and mitigated by using proper site encryption and secure downloading. SSL, HTTPS, proper certificates, that sort of thing.

The other, much smaller risk is if the end-users computer is compromised and the image is stolen from there - but this is well outside your liability and falls on the end-user to protect their data.


Is publishing CRLs over HTTP a potential vulnerability? I noticed that at least one major CA (Comodo) publishes their CRL over HTTP rather than HTTPS.

This seems to me to be somewhat of a vulnerability, as an attacker could hijack the HTTP connection that seeks to download the CRL and when HSTS is in use at the very least execute what effectively amounts to a DoS attack on the domain. (Because with HSTS active, browsers should not allow the user to bypass the invalid certificate warning; see RFC 6797 section 8.4 and section 12.1.)

While CRLs are normally signed, and it would seem that any sane implementation should reject a signed CRL that does not pass signature validation, I haven't seen any way to determine the signer of the CRL in any web browser, so even signing a replacement CRL with your own root certificate key appears to be a relatively low-risk operation. And this of course assumes that the browser requires that the CRL is signed in the first place; if not, you can just replace it with a non-signed CRL. (And of course, if the implementation does reject a signed CRL that fails signature validation, or even non-signed CRLs, it becomes trivial to trick the UA into using a certificate that has been revoked but which has not yet reached its expiration date.)

Is this an actual potential problem? What checks are normally performed by UAs with regards to CRLs to prevent it from becoming an actual problem?

There is no such thing as a non-signed CRL; the signature field is mandatory, and any system that uses the CRL will verify the signature.

In pure X.509, a CRL will be deemed "acceptable" as a source of information about the revocation status of a given certificate E if it is signed by an "allowed revocation issuer": the CRL's signature must match the public key contained in an already validated certificate, whose subjectDN is equal to the issuerDN of E (you can have a distinct DN if E contains the relevant CRL distribution point extension and the CRL has a matching Issuer distribution point extension; but let's forget this additional complexity). Complete rules are exposed in section 6.3. Note that "pure X.509" is supposed to work in the context of the Directory, the kind-of worldwide LDAP server that references everything under unambiguous Distinguished Names.

Since the Directory does not really work, because it does not, as it were, exist at all, existing implementations tend to implement stricter and simpler rules. Generally speaking, a Web browser validating a certificate E issue by CA C will accept a CRL only if it is also signed by the same CA, with the same key. This rule keeps path validation simple and bounded (otherwise, you may imagine a situation where you must get a CRL for each certificate in the path, and each CRL is to be verified against another CRL issuer certificate that requires its own path validation, and so on). Therefore, producing your own CRL relatively to your own root CA is unlikely to have any actual effect.

CRL, like certificates, are thus objects which are always signed, and never used without verifying that signature(*), so they can be served over plain HTTP. Using HTTPS to serve CRL is just wasted resources; it may even prevent CRL download from working since some implementations (e.g. Windows) refuse to follow HTTPS URL when validating certificates (be it for CRL, OCSP, or extra intermediate CA download), because that would mean SSL, then another certificate to validate, and possibly an endless loop.

(*) I here exclude root CA "certificates", traditionally self-signed; these are not real certificates in the X.509 sense, but only objects that mimic the encoding rules of certificates.


What could be the order of these ciphers following as first criteria the security and just then the performance? I need some guide to decide in which order I must put the following ciphers if I want prioritize security and in cases of tied, consider performance to decide.

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384

And what about this list?

DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256

different list, I don't want mix them ;)

Security: if you don't do stupid things like using a 512-bit RSA key, these cipher suites are all equally secure: they are all very far in the "cannot break it" zone. So that's a meh. You cannot say that one is more secure than any other.

With an exception though: the "ECDHE" suites use an ephemeral key pair for actual encryption; since the corresponding private key is never stored in a file, this grants a nifty property known as Perfect Forward Secrecy. Basically it makes communications immune to attackers who steal a copy of the server private key after the fact. PFS looks good in technical audits.

Performance issues exist only after having been duly measured. As Knuth said: Premature optimization is the root of all evil. So you should not ask such questions; you should try it out and measure. In any case, answer will depend a lot on the context: involved machines, bandwidth, usage patterns...

Short answer: won't matter.

Long answer:

The "GCM" cipher suites use GCM; the non-GCM cipher suites use AES in CBC mode and an extra HMAC (here, with SHA-384). Performance issues depend on the involved systems:

On small 32-bit systems (embedded ARM...), the MAC part of GCM will be expensive, but so will SHA-384 (because 64-bit computations...); I'd guess a tie.
On PC, AES cost will dominate;
... except on very recent PC with AES-NI, where AES is very fast, and so is GCM.

So the GCM cipher suite should, usually, be a better bargain. However, it takes a lot of bandwidth, or a very small CPU, to actually notice the difference. Even without AES-NI, a normal server has enough juice to do SSL at full gigabit bandwidth, with CPU to spare.

For the asymmetric cryptography part:

The ECDHE suites imply on the server an (elliptic-curve) Diffie-Hellman and a signature for each full handshake, whereas the ECDH cipher suites require only the elliptic-curve Diffie-Hellman, and half of that one is already done.
... But a normal PC will crunch through thousands of those per second and per code, so this very rarely matters.
... Especially since normal SSL clients reuse SSL sessions, which means that the asymmetric cryptography occurs only for the first ever connection of the day from a given client.
ECDSA signatures are faster than RSA signatures.
... Depending on key sizes, of course.
... But for verification, this is the other way round.
... And, again, it takes an awful lot of new clients per second for this to actually matter. A normal PC will do hundreds of 2048-bit RSA signatures per seconds, thousands of 256-bit ECDSA signatures per second.
ECDSA signatures are shorter than RSA signatures, so this saves a bit of network (but, again, only a few dozen bytes per full handshake).
DHE and ECDHE cipher suites also imply a few dozen extra bytes per full handshake.
DHE is like ECDHE but without the elliptic curves. You need it to use bigger mathematics to achieve the same security levels (2048-bit modulus instead of a 256-bit curve point), so it is like RSA vs ECDSA: a bit bigger, a bit slower, won't matter in practice.

So, really, you will not make a useful distinction based on security or even performance. In fact, you are already making a fashion statement, by insisting on AES-256 (instead of AES-128) and SHA-384 (instead of SHA-256). You may as well keep it on and bring it to its logical conclusion: use as much GCM and elliptic curves as possible ! This will grant brownie points from impressionable auditors.


RSA uses substitution and shuffling? I've been doing some searches for RSA and it appears that it uses shuffling but not substitution. Is this true?

Simple explanation of the algorithm:
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/

I've been doing some searches for RSA and it appears that it uses shuffling but not substitution.

RSA is a mathematical algorithm. Neither of these terms is applicable to it.

Generally speaking, the terms "shuffling" and "substitution" are generally only applicable to extremely simple, pre-electronic cryptographic techniques -- Vigenère ciphers, columnar transpositions, and the like. They are not especially relevant to modern encryption.


What happens when a spoofed source IP packet is dispatched out of a private network with NATing Suppose as an attacker i want to carry out a Ping or SYN Flood attack..

I can change the source IP of the packets generated at my machine to a false/spoofed public IP address so that replies go to that spoofed IP to avoid detection.

A WiFi router or any device for that matter .. would it drop the packet if source IP was a spoofed public IP or does it forward the packet to the destination or does NATing take place and the reply comes back to the router public IP address?

How would IP Spoofing work in this case? ..what is the general behavior of networking devices here

Edit:  If there are so many variations in behavior of networking devices .. then how do Botnet operators manage to carry out DDoS from their slaves .. since majorly bots are in NATed home/business environment?

There are three likely behaviors as the packet is sent from the LAN to the router:

The router apply reverse route filtering and drop the packet.
The router does not filter. Instead the router treat it like any other packet from the LAN, which means the source IP is replaced with the IP of the router, and the router create a connection tracking entry.
The router does not apply filtering or NAT. Instead the router forward the packet with spoofed source address.

In the first case, nothing more happens. In the third case, the packet may be dropped or forwarded by the ISP. In one of these cases the spoofed packet makes it all the way to the target. But no reply will be coming back to this router, because it would go to the spoofed IP.

The most interesting case is the one where NAT is applied to the packet. The ISP will no longer be able to drop the packet based on the source IP, because in this case the source IP is in fact valid as far as the ISP is concerned. But this is not very harmful because the packets can be easily filtered based on source IP once they reach the destination (assuming the flood is large enough to be noticeable at the destination). It also cannot easily be abused in a reflection attack, because the replies go back to the NAT router.

What happens to any replies coming back to the NAT router is more interesting. They will match a connection tracking entry. But after the NAT has been applied, the destination address will not be inside the LAN, but externally. At this point there are a few possible outcomes:

The router may refuse to forward the packet because it would be send back on the interface from whence it came.
The router may forward the packet back on the outside network as soon as it has applied NAT according to the connection tracking entry.
The router may attempt to perform NAT on the packet again, because it would be leaving on the external interface.

The first case where the packet is dropped, is not particular interesting or harmful.

The second case where the packet is forwarded back on the external network is more interesting. This is the case where the NAT prevented any spoofing from taking place in the first place, but a side effect of this is that on processing the reply, it actually produces a packet with spoofed source IP (effectively the source and destination IP of the original packet has been reversed).

If the ISP does not filter the packet due to invalid source IP, the return traffic will then be forwarded to the IP which was spoofed in the first place. And on arrival will look pretty much the same as it would, if no NAT had taken place at all.

But since this involves three trips across the external connection of the attacking network, the rate of attack traffic is limited compared to what it could have been.

If the router tries to NAT again, stuff gets a bit interesting. The issue here is that it isn't the first packet of a flow, so the NAT layer may not know how to deal with it. So the packet may be dropped because of NAT being applied without having seen the first packet of the flow.

It is also possible that a connection tracking entry is created. Since that newly created connection tracking entry was obviously not applied to the first packet of the flow, there is no way this could work at all for a TCP connection. But other protocols could possibly work even in such a scenario. However since this particular packet is due to spoofing, nothing good will come from NATing it.

If we assume this was a TCP SYN-ACK packet, and the router does NAT it again in spite of not making any sense at all, then the SYN-ACK will be forwarded by the ISP. The SYN-ACK will trigger a RST response (assuming the destination is functional), the RST will then go back through both connection tracking entries and get forwarded to the host from where the SYN-ACK came and clean up the connection.

As you can see, there is lots of ifs in this flow. And there is likely some possible outcome, which I have not considered.


Webapp vulnerability scanner that understands continuations I'm researching XSS vulnerabilities in a web application which uses continuations.
That means that for a given form, the URI the form data is posted to is unique and different every time.

A first GET request displays the form with its unique URI such as:

  http://test.local/webapp/4b69615449222508116a1e562e1e0a458e4d6351.continue

Then the submit action does the POST request.

Is there any free (or better open source) security scanner which understands continuations and is able to do the GET request before each POST request the fuzzer is trying to send ?

Yes most scanners can do this.

For example, Burp Suite supports macros which allow you to configure a sequence of requests. The support is quite neat as various different Burp tools (scanner, intruder, repeater, etc.) automatically make use of the macros transparently.


How can I compute the value of the ASP.NET forms authentication cookie? How can I compute the value of the ASP.NET forms authentication cookie?

It completely depends on the settings you've chosen.   The value of the forms authentication cookie is a FormsAuthenticationTicket.   The ticket has a number of properties, and it is then:

Serialized before further processing.
At this point it can either be signed (using a message authentication code), or encrypted, or signed and encrypted, or neither.
If it signed, it could be signed using one of a number of mechanisms as specified in the machine or application configuration.
If it is encrypted, it will be encrypted using an algorithm and key specified in either the machine or application configuration.

So, you'll have to know which specific configuration you're targeting (and the specific keys, if applicable) in order turn the value of the forms authentication cookie into something usable.


Diffie Hellman parameters still calculating after 24 hours I have a fresh install of Arch Linux on a RaspberryPi model B. I'm setting up OpenVPN and using easy-rsa to generate initial keys and certificates. All went fine until I ran ./build-dh. It is now 24 hours later and the script is still running.

I have previously configured OpenVPN on other devices and the same RaspberryPi, but under Raspbian. And I don't remember this command ever taking so long. Last time I used 2048 bit key and it took about an hour. Now I'm trying with a 4096 bit key and it's been more than a day.

Does anyone have any previous experience with this? How do I check if it's just not executing in a loop?

This is the script I'm using:

#!/bin/sh

# Build Diffie-Hellman parameters for the server side
# of an SSL/TLS connection.

if [ -d $KEY_DIR ] && [ $KEY_SIZE ]; then
    $OPENSSL dhparam -out ${KEY_DIR}/dh${KEY_SIZE}.pem ${KEY_SIZE}
else
    echo 'Please source the vars script first (i.e. "source ./vars")'
    echo 'Make sure you have edited it to reflect your configuration.'
fi

Here is my top output, openssl is at ~67%:

Thanks.

Turns out it's a property of the algorithm to search for the so called strong primes and thus increases the computation requirements quite a bit. Solution came from my other ticket here.

Maybe it is starving for entropy. Try to see how many bit it has in the pool

cat /proc/sys/kernel/random/entropy_avail

If it has indeed not enough bits it is often enough to smash on your keyboard or start a network operation. If it still cannot gather enough try with haveged


Security Implications of using Base64 Encoding with Encryption Are there any security implications of converting a byte-array encryption key into a Base64 string before use?

I am creating a generic encryption helper for a project, and for the sake of consistency and generality, I use byte arrays for all inputs and outputs (plain data, key, salt, etc)

However, the encryption library I use internally expects strings. I am worried that encoding the key as a base64 string before use might somehow weaken it's strength in terms of entropy, etc.

Any thoughts? In general, does Base64 encoding affect encryption strength in any way?

As long as the key is converted back into the binary format before use, the bit-dilution caused by the base-64 encoding will be undone.

However, if you're passing keys around an application be careful of how you do it.  Wipe text buffers, minimize transits between methods and applications, etc.


How to ensure two messages are from the same party I need to verify that two messages, that came over distinct channels, come from the same origin:

without knowing anything about the origin beforehand
the channels are one-way, only one message may be sent over each
the sender can have recipients public key

The sender has a random number that identifies them. Apparently I can send the ID encrypted with two different public keys, one for each channel? Is there some simpler method? I was thinking about something like two commutative functions, f and g so that f(g(x)) == g(f(x))? I don't need to know the ID and it would be a bit safer if I didn't. I just need to know that the messages are from the same sender.

Simplest mechanism I can think of:

Client picks a large random value as an ID.
Encrypts the data, containing the ID, with the two separate public keys.
Sends each message to the two different channels.
Server verifies that both IDs are equal and that both signatures are OK.

Your security here relies on a combination of the security of your asymmetric cipher (e.g. RSA) and the difficulty in guessing an ID. If you use an appropriate CSPRNG, 128-bit IDs should be sufficient.


Is it safe to display version information on a public webpage of your web app? I know an ecommerce company which has a public facing website at, say www.app.com which has a page www.app.com/version.jsp which is also publicly accessible. The page has the following information.

Build Info
Path:   /root/version/app/v5.6/b10
Server:     appUSA-prod-srv1
Date:   09/10/2017 6:21 AM
Source:     svn@svn
CI: Link (this leads to an internal link which is inaccessible to public)
Gradle is used in newer apps.

Its nice for developers/QA to know the exact version and build in production by simply checking the page. But, is it safe or advisable to make such a page publicly accessible ?

When in a production environment, the less non-critical information that is handed out the better your security surface will be.

Version information and a product's name can be used to narrow the scope down of attacks that can be used against an application.

Without knowing the in's and out's of the application, it's hard to know if it is in fact deployed as a "production level" application.

I will add that with SVN controlled applications, version information becomes useless to an attacker because the application likely to be rapidly updated.

EDIT: For further clarification, I will also mention that many protocols and pieces of software will pass a version parameter. This is to ensure that the program is talking to a valid version. Imagine an older version of the app talking to a new instance of server software. Things could either go very bad, or just not work at all.


SQL Injection - LIKE Clause As part of a capture-the-flag assignment, I'm supposed to perform SQL injection using the LIKE clause to obtain the flag. I'm new to this and I've tried the following injections:

(The username required to login is 'admin', so I've performed the following injections in the password field)

'; SELECT password FROM users WHERE username LIKE 'admin%'; --
' OR '1'='1   (I ignored the LIKE clause)

I've also tried variants of (1.) but I'm still stuck.

Is there something I'm missing? Any hints would be appreciated!

PS: I don't have the database schema or table layout

You are suposed to bruteforce the password using the following algorithm:

SELECT  * FROM users where username = "admin" AND password LIKE "A%"; #INCORRECT

SELECT  * FROM users where username = "admin" AND password LIKE "B%"; #INCORRECT

SELECT  * FROM users where username = "admin" AND password LIKE "C%"; #CORRECT

SELECT  * FROM users where username = "admin" AND password LIKE "CA%"; #INCORRECT

SELECT  * FROM users where username = "admin" AND password LIKE "CB%"; #INCORRECT

SELECT  * FROM users where username = "admin" AND password LIKE "CC%"; #CORRECT

And so on. You can write a simple python program that does that automatically :)


A String that if encrypted or decrypted with the same key gets an English word/statement in both cases I am trying to find a string S that if encrypted using a Vigenère cipher with Key K, it gets an English statement/word that makes sense. Additionally, if the same string S is decrypted using Vigenère cipher and again using the same key K, it gets another English statement/word that makes sense as well.

I think if I try to find a string that has a certain structure I could find such a case, any other hints from security experts that could help me find such a string and key?

If you're looking for a simple and novel way to do this, why not assign each word w an integer value, and each word m in the message an integer value, then map them across based on the key? As long as your mapping w <==> m doesn't exceed word group boundaries (e.g. nouns, pronouns, verbs, adjectives, etc. are mapped to the same group) and your conjunctives are appropriately mapped, you could feasibly produce semi-legible sentences as your ciphertext. The mapping could quite easily be generated by seeding a PRNG with your key value.

Assuming that you don't care about leaking the grammatical structure of your plaintext, and that your mapping w <==> m is uniform and random within groups, you actually have a reasonable level of security for large plaintexts.

I certainly wouldn't use such a cipher for anything important, but it'd be very interesting to see the kinds of ciphertexts you might produce.


Can my employer see my phone browsing history on my work desktop? What if I logged in to my work PC using my personal Google account?

Can my employer see what I have been googling on my phone under my work desktop's browsing history? What about under “my activity” in Google? Would it be auto synced?

Simply put, I logged in to my work PC and personal mobile using the same Google account. So would my private searches done using my phone be available on my work PC?

As mentioned in some comments, this will depend on the setup your employer has on the pc and in the network you are working on. You are in your rights to be concerned about your privacy and we all should always keep an eye in the correct use of personal data even if it's something simple as our search results and youtube video history.

If your gmail accounts are synchronized in the browser, all your synchronized settings will be in all of your devices. If you are just logged in, you will need to access account settings and view history from there. This means that whoever has 'physical' access to a device with your account can see your activity. This does not mean that your employer has access to it even if that info is on the work computer, unless he walks to the computer and uses it.

But there are malicious ways to gain more information or access to your accounts like a remote monitoring tool. If your work pc has a remote tool, then he can get access to the PC remotely and view your stuff since the accounts are already logged in.

Another way can be to have a keylogger installed in the background and everything you type will be recorded by the employer. They can get passwords and other information from you.

Another malicious way is that the network has some type of proxy (mitm) which all network traffic goes through. This way they can get your password, cookies or any other useful stuff. This way they can impersonate you on a different device and gain access to your account.

So if you want to be 100 percent sure you are not being monitored, check all your account settings, your connected devices, check for malicious software and backdoors in the pc... Then use a VPN when you are at work.


How to handle decomissioned/donated/RMAed printers? Printers, nowadays, almost always include some form of non-volatile storage that keep tracks of pretty much everything that went through the device.

In the case of larger, "departmental" system that often combine print/scan/fax functionality, that storage can be pretty massive and often contains traces of confidential documents.

I am wondering how a small(ish) structure could safely handle these devices once they are to be moved out of premises (either permanently or temporarily).

Are there standard procedures one could follow to properly clean these devices ?

There's 2 types of MFP's that I have seen:

Those meant for SOHO/Consumer. Those does rarely have any permanent storage for documents, rather its a little flash area that stores configuration data only. If the configuration contains sensitive information, a factory reset is enough to clear information.
They very often use standard SDRAM sticks (either SODIMM or standard DDR) or customized variants of these, to maintain temporary storage during printing. To clear these, its enough to leave printer unplugged from Power socket, with the power button on, for a day, to clear any resudial data and charge in capacitors.

Then we have those large copier Machines like Konica Minolta C224 and such. Those variants do have a harddrive. The harddrive does not contain any inportant information (with "important", I mean data Worth keeping. Non-important information, like cache, can be confidental too, but can be safely thrown away) for what I have seen. (only in the cases when the "storage box" function is used on the printer, the harddrive contains info Worth keeping, else the HDD only contains cache, and IMHO the "storage box" function is pretty useless)
Thus a standard "zeroization" can be done, that will do a "secure delete" on the drive. On Konica Minolta, this action can be initiated from the standard "administrator -> security" menu, without technician access code. However, such a action will disable the printer aswell because this also erases the second stage firmware that is also present on the harddrive, thus the harddrive has to be reloaded with the latest firmware for the printer to become functional again, and this can only be done with access to the technician access code.

Since the harddrive mostly contain non-important data, the harddrive can IMHO be safely zeroizated everytime Before the MFP leaves the premises, regardless of it it leaves temporarly or permanently.
In most times, the harddrive is also behind a access door, and can be removed to physically destroy it if requires. The harddrive can then be replaced with a new harddrive to recommision the printer somewhere elsewhere, so its NO NEED to destroy the whole printer.


Why isn't applying security and usability best practices enough? I have a homework question that suggests that applying security and usability best practices isn't enough to create a secure and usable system. What am I missing? Why isn't this enough?

If I follow usability best practices will I end up with a usable system? I think yes.

If I follow security best practices will I end up with a secure system? I think yes also.

So what am I missing?

I think you dropped an important word in the homework question. "Applying  security and usability best practices simultaneously isn't enough to create a secure and usable system."

The concept being explored by the question is the intersection of usability and security. The most usable system is not secure, and the most secure system is not usable. If you try to be the best of both, you'll fail at one of them.

For instance, a security best practice is to use passwords. But passwords are horrible for usability. How and where do you draw the line between a secure system and a usable system?

So, the idea that I think you missed is not the idea of following best practices, but trying to follow different best practices at the same time that tend to be at odds with each other.


Does a VPN utilizing PPTP and MS-CHAPv2 without encryption pose a risk to security? I see there is no encryption for ms chap v2 (providers settings.)

Furthermore, what can I do if the provider refuses to cooperate and improve security?
Can a vulnerability in this setup be exploited by people on the same LAN, or between my port and the provider's equipment?

It is a security risk, as Point-to-Point Tunneling Protocol (PPTP) is obsolete with many well known security issues.
Thorough explanations from Bruce Schneier's research:

Cryptanalysis of Microsoft’s Point-to-Point
Tunneling Protocol (PPTP)
Cryptanalysis of Microsoft’s PPTP
Authentication Extensions (MS-CHAPv2)

Easier to digest:

Olivia Scott: The PPTP VPN protocol: Is it safe?
David Wibergh: PPTP has become obsolete
Microsoft says don't use PPTP and MS-CHAP


unauthorized devices appear in windows 10 network drive SMB Few days ago I was trying to access a shared folder via SMB on Windows File Explorer and noticed 3 strange mobile phone devices appear listed in the network drive. I never owned any of the mobile devices that listed in the drive

Being the only person using my home wifi network nobody accesses my network resources

The Phone listed in the screenshot is the suspicious device that had me wonder how is it in the network

My question is
How would you investigate if noticed unauthorized devices (mobile phones or laptops) appear in your windows 10 network drive ?

The first thing, in any network, is to check the access logs. What connected to those shares? From there, you gather as much information as you can on the devices/users connecting. That's how you investigate.

Monitoring wifi for unauthorised devices is usually done on the WiFi AP. But it is usually better to have the strongest encryption and a strong passphrase to join the network.


How to deal with prototype pollution attack vulnerability in lodash? lodash has been reported to be vulnerable to the so called prototype pollution attack in versions up to (excluding) 4.17.5
See https://nvd.nist.gov/vuln/detail/CVE-2018-3721

Now lodash is the most depended upon package in the JavaScript eco system. The impact is that almost every at least mid-scale project has gazillions of different lodash dependencies and sub-dependencies in different versions included (run npm ls | grep lodash in a JS project of your choice to see for yourself). Now it will take lots and lots of effort and a lot of time to contribute to all of the open source projects that use lodash in version < 4.17.5.

Please explain, how can this vulnerability be used by attackers and what would be the right way to deal with this issue in a large scale frontend that has A LOT of production dependencies using lodash.

These are several questions cramped into one, so I will try to answer each one individually:

What is prototype pollution and how can it be used by an attacker?

I don't know how much JavaScript knowledge you have, so I will try to remain as generic as possible. JavaScript uses prototypes extensively to implement object inheritance. Basically, whatever you write into the prototype will be in the object instances. The Mozilla documentation will explain this far better than I could.

According to the report on HackerOne, if an attacker is able to insert their own data into lodash, they are able to add their own code to the object. The following PoC demonstrates this:

var _= require('lodash');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';

var a = {};
console.log("Before : " + a.oops);
_.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);

If you run this code, you can see that a is modified, even if it is never written to directly.

So how does this affect your application? Well, this depends on your code. There is no "catch-all" answer. In some cases it can be a denial of service, in others a remote code execution.

For instance, one could replace the function toString() with a literal string. Attempting to call a string will result in an error, thus leading to a denial of service.

How can a large-scale application deal with a vulnerable package?

Either update your lodash version as soon as possible or apply a manual backport patch yourself. It might not be easy, but it's absolutely necessary.

If your application never processes any user input, then you may delay the update until you can, but it should be pretty high on your priority list.


Protect linux kiosk display We use a small computer with linux attached to a big tv to display some data to the public.
Normally, there is no keyboard connected. When a keyboard is connected at boot, we start the configuration screens. A browser displayed in full screen after boot.

I protected the BIOS with password.

How can I avoid that someone connects in single user mode to access to files.

Is there other things that I can do to protect against hack ?

Thanks in advance

You could always utilize a USB port blocker to physically block access to any USB ports.  You only really need one of these per device... the other USB ports can be dealt with super glue (or most likely a different non-permanent solution).


Is there any functional distributed timestamp server available? If not what about this homebrew solution? Objective

A secure Arrow of Time with unpredictable future behaviour to stop attackers or DDoS BotNets from pre-calculating proof-of-work and other gateway protections for P2P/F2F. A distributed solution in so far as there isn't enough free centralised timestamp servers to pick randomly amongst them to foil attackers.

Due Diligence

I was looking for a distributed timestamp server as centralised solutions are often commerical (example) and easily coerced in any case. The only functional distributed one I could find was as an implicit behaviour of the Bitcoin network. Which while worthy, is too heavy for a distributed timestamp service and has different design goals.

So in frustration of absent(?) distributed solutions, it seems time to homebrew...

Homebrew

We want network consensus of a hash value / key pair per time interval that a randomly selected node will sign as a ad-hoc TSA server for that time interval only. The bigger the distributed network, the harder to subvert; assuming 50% subversion required to control the network result.

  Each node generates a random 32 byte network hash candidate as a ECC or RSA public key.
  Each node hashes the candidate through an expensive scrypt() call, using the previous network hash as the salt. A new network
  starts with a zero bit salt.
  All nodes send each other both their network hash candidate and the (32 byte) scrypt() result.
  Each node sorts all received entries in ascending order of scrypt result and picks the median* entry. Each node then publishes
  (votes) the hash candidate of that entry to other nodes**.
  Each node collects votes. Multiple votes and votes from IPs that didn't publish a Step 3 result are dropped.
  The most voted hash candidate is run through scrypt() again to check if the hash candidate was honest. If not the next most voted
  candidate is checked.
  The most voted valid hash candidate is the next network hash value.
  Any node may store or publish each authoritative network hash as they occur to some external directory for non-repudiation if desired.
  Each peer also supplies authoritative hashes to new nodes on request.
  The node that supplied the successful hash candidate signs any TSA-style requests with the associated ECC or RSA private key during
  the appropriate network time interval; then discards the private key.
  (Optionally if a winning node is liable to disappear if it wins,
  include a Step 3B where each node must send its private key to a few
  other redundant nodes.)

An attacker attempting to control the next network hash value would need to:

Have many nodes or the ability to spoof extra IPs for dispatching colluding hash candidates that outcompete other alternate medians.
Have a beefy supercomputer capable of ~2^254 * scrypt_cost processing power to create colluding hash entries within the network time interval. Pretty unlikely.

Question

Is this sane, or have I (re?)invented a square wheel?

 * Or nearest neighbour below the median if an even set of values.
 ** The entries a given node received and thus the median may differ somewhat due to lost packets, dropped nodes, attacker interference and latency or congestion at the edge of network - hence the voting stage.

First things first. What's the problem you are trying to solve ? What is the attack model ? We cannot tell whether a protocol achieves a given goal if the said goal has not been given.

Apparently, you are dissatisfied with Time Stamp Authorities as they are commonly used. Let's see what TSA do and on what security property they rely.

A TSA emits time stamps, where a time stamp is a signature over a structure containing the signature date and time, and a hash value. By this signature, the TSA asserts that the hash value "existed" at the specified time. "Existence" requires some semantic caution, since we could say that the set of all sequence of 256 bits is well-defined mathematically, and finite, so it "exists" already. What we mean is that, given a message m and a time stamp t which contains h(m) and the time T, then "someone" must have handled m before time T as a sequence of bits in its own right.

A time stamp is a verifiable proof of existence of a given message m at a past date T, and can serve as a basis for constructs which need such proofs (e.g. long-term archival of signed documents, which must be verified long after all the involved certificates have expired). To verify a time stamp, we must have access to the public key of the TSA, and the message, and recompute the hash, and verify the signature from the TSA.

The goal of the attacker is to produce at date T' (after date T) a so-called time stamp t over a message m which did not exist at date T, but such that the verifier will accept it nonetheless as a proof. There are several ways by which this could be done:

Tweaking the message m until h(m) matches a hash value for an existing time stamp (for another message) which bears the date T. This method is not feasible as long as h is resistant to preimages (included multi-target second preimages).
Subverting a TSA to issue (sign) the fake time stamp.
Stealing the TSA private key (by breaking its public key, or purloining the private key from where it is stored) in order to sign the fake time stamp.
Convincing the verifier that a given public key is owned by the TSA, whereas it is in reality controlled by the attacker.
Tricking the TSA into assuming that the current time is T, so that it unwillingly issues time stamps "in the past".

A very important point to make is that all of this is about security of the involved elements (hash functions, private keys, clocks) at the current date, i.e. not at date T. It is not sufficient to ensure that everything was "secure" at the time the time stamp was issued; security must be enforced as long as the time stamp is to be verifiable. In all generality, since time stamps tend to expire (because security of the private key cannot be maintained indefinitely, because of possible cryptanalytic advances), time stamps have to be chained by regularly re-timestamping (e.g. as is described in ERS).

What you describe seems to be a protocol by which a number of "nodes" may come up with a shared agreed-upon designation of one of them. Apparently you want that selection to be somewhat "random", i.e. such that none of the node may arrange to be selected more often than any other. However, as far as I can tell, this is not achieved: a dishonest node may invest in some CPU in order to compute several hash candidates, then keeping the one which is closest to the middle-point of the hash space, thus improving its chances of being selected.

But, more importantly, whatever you do at that point may only offer some protection at a given date against "subversion". This does not do what we want with regards to time stamps. For instance, suppose that there is one (only one) TSA which is corrupt. All that TSA needs to do is to wait for being the "TSA du jour" and be allowed to issue valid time stamps in a time range including the time T. The corrupt TSA faithfully follows the protocol, except for one point: at the end of the day, it does not destroy its private key; instead, it keeps a copy. From the outside, this is completely undetectable. But this allows the attacker to produce afterwards as many fake time stamps as he wishes to, all for alleged date T (any date within the range during which the corrupt TSA was the TSA).

Also, nothing is said about how the verifier is supposed to learn the correct public key for the agreed-upon TSA at date T. All games about selection of one TSA have any worth only as long as this is verifiable afterwards. I don't see anything in your protocol about that point.

Summary: you don't say what your protocol tries to achieve but I am pretty sure that:

this is not what we want,
and it fails to do it properly anyway.

What can be done to make time stamping more reliable and, as you say, "distributed", is to use several TSA in parallel. When you need to time stamp a message m, go ask for time stamps over h(m) to several TSA. Say that there are n TSA in use, and TSA number i returns a time stamp bearing date Ti. Then consider the set of time stamp to prove the existence of m at date T = max(Ti): indeed, when a time stamp states that a given message exists at a given date, it implicitly also states that the message has continued to exist since that date. By taking T to be the latest of all dates in the n time stamps, you are simply using all time stamps to individually prove (independently of each other) that the message existed at date T (and possibly before, but definitely at date T).

Under these conditions, your time stamping is secure until the attacker succeeds at subverting/breaking/framing all the n TSA. Now THAT is robust. And it is decentralized and efficient; the TSA do not need to talk to each other or even to be aware of each other's existence.


How many accounts should I have in an information system? Is it a problem to have more than one account in an information system from security point of view?

Let me clarify a bit. It is a bank system. I wonder if  having a CSO (customer service officer) with more than one account associated with him/her (more than one login name and password for the same task) would result in some security breach. Can you see a breach specific to this scenario?

You should certainly seek to minimize the number of accounts you have on a system, however I disagree with Ralf that multiple accounts are always a bad idea.

Yes, if you have a security model based on two sets of eyes (propose/accept) then multiple accounts subverts this. OTOH, not only do I always have a user account on the systems I admin, I disable remote acess for root. That way I need to make a conscious decision to switch on my super powers.

So, as usual, the answer is that it depends on the security model.


Default accounts shutdown, halt, and sync - still shipping? I'm curious as to whether, and if so why, Unix and Linux distributions still ship with default accounts shutdown, halt and sync. Specifically (from a Red Hat document),

sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt

From a historical perspective, these accounts were set up so that one could log in at the physical console with these accounts' credentials (traditionally they shipped with a null password, so all you needed was to enter the user name) and properly shut down a system without having to provide the root password.

This could be useful in the case of a desktop workstation, but is questionable in the case of a server system. I don't recall there ever being any protections against logging in from remote terminals or the Internet with these accounts (unlike root itself) and shutting down the system, which creates an extreme risk of a DoS attack. Therefore, best practices have dictated for years that these accounts be removed on sight, or at the very least, locked like all other default accounts to prevent use. As default accounts go, these are probably the most dangerous.

So I'm wondering if the OS vendors have finally gotten the clue not to ship systems with these rather egregious defaults, or if there is still any purpose for having them around?

if the OS vendors have finally gotten the clue not to ship systems with these rather egregious defaults

In all modern OSes, these accounts ship disabled, if at all. The presence of these accounts is not an egregious default. They're only a risk if you enable them in some way, for example by setting up a password (which only root can do).

Removing the account, or declaring it as locked or expired, protects against the risk of an administrator accidentally setting up a password for the account. As risks go, there are bigger ones.


A fake Snapchat account has been created in my name A fake Snapchat account has been created in my name, and it is currently being misused.

How can I figure out who created it? Going to the cyber cell is a big task. I just want to know how I could get hold of the fake account's IP address.

This kind of thing happens all too often, and there isn't much you can do about it. You aren't going to get ahold of the person's IP address, or be able to find out anything beyond what is on the public snapchat account profile. Snapchat could determine a lot more, for instance IP address and the email address used when creating the account. They are not going to give you this information though, and even if they did give you the IP it's not good enough to tell for certain who the perpetrator is, especially if they are using TOR or a shared IP address.

Your best bet is to contact snapchat and tell them you are the victim of identity theft, and ask for the account to be closed. They will have a process for that.


Purpose of Secure Element What is the purpose of embedding a Secure Element to enhance the security - especially the storage of keys- if a key is required to connect with it in order to get its secrets?

For example:
Let's suppose I have a host that is not secure enough to store keys in its ROM. I will hence store keys in a remote Secure Element that will be connected to my host.
However, it would hence be required to secure the communication with the Secure Element to keep the confidentiality of the informations shared between the host and the Secure Element, such as the keys.

Now here's the problem: how should I store the secret to connect with the SE (symmetric Secret key or Certificate), if storing the keys was the exact reason of integrating a Secure Element ?

It seems like a chicken and the egg problem...

The advantage of using an HSM to store your secret keys is that the actual decryption keys will never leave that module. Even when an attacker will be able to obtain the access keys to the HSM, they will still need physical access to the HSM in order to do any decryption.

Contrary, a normal software stored key/passphrase is easily copyable information which can be used for decryption anywhere in the world without you even noticing.

An additional advantage of using an HSM is, that they often (at least the expensive ones) offer an audit trail. So even if an attacker can get access to it and decrypt some data, you will be able to detect it.


Secure touch kiosk system without updates? We have a discussion here, if an internet enabled kiosk system can be set up securely without updating the system regularly.
The facts in short:
We are developing a new software product which offers a "station version", means it runs as a kiosk systems.

it will use a touch-display and a Win10home PC Stick
no external or virtual keyboard will be used for the GUI interaction
the frontend is a webapp which is hosted on our server
the Chrome browser will be used in kiosk mode to display the webapp
no additional software will be installed, just a clean Win10home, Firewall and Chrome
all Windows services will be disabled (e.g. Updates)
all ports are closed except 80 and 443 from inside out
no access to the internet except the URL to our server

The questions we are discussing are:

Will it be possible for an advanced user to leave the Chrome kiosk mode anyhow?
Our result: we tried everything but did not succeeded, so it seams to be locked.

Will it be secure to leave the system in the setup state, discarding any update for Win 10 and Chrome?
Our thoughts: of course we know, that it is no good idea to skip software and especially OS updates! But we believe by isolating the system, so it can only access our server and closing all ports will do the trick.

I am asking this because if there would be a secure solution we will not have to add high frequent service costs and therefore could offer the system for a lower price.

No. Even if the user cannot do anything by itself, there is possibility by cooperation of a web site (that the hacker made itself), would be able to escape the kiosk mode. This with the addition that Chrome, upon detecting a security problem, will usually prompt the user if he want to proceed. If both the end user and website is malicious, then the malicious user will just proceed through.

I would suggest using a Linux Kiosk distribution instead. There is Webconverger, and there is Proteus. The advantage is that these can be run in "live mode", and use a write-secured USB memory (For example, https://www.kanguru.com/storage-accessories/flash-blu30.shtml ) where you flip the write protect switch, to prevent writes to the memory.

When you use such a solution, you combine this with a simple timer, that Cuts the Power to the kiosk, lets say every night when the location where the kiosk is placed, is closed. The advantage is then, that ANYTHING that a malicious individual may have done to the kiosk, is instantly cleared out and the device is guranteed Clean every morning.

If you for some reason MUST use windows 10 with Chrome, there is a possibility to run this in write protected mode too.
This can be accomplished here:

How to enable on Windows 10:
https://msdn.microsoft.com/en-us/library/windows/hardware/mt572001(v=vs.85).aspx

How it works:
https://msdn.microsoft.com/en-us/library/dn449416(v=winembedded.82).aspx

Then when this are activated, you can turn on the Write protect switch on the USB memory without problems. Then you can apply the timer function as I describe, that will reboot the computer each night.


What is the shortest malicious XSS possible? Sometimes you stumble upon input fields that don't escape input properly, but who still appear to be to short to actually be used for anything malicious, at least to someone with my limited imagination.

This made me wonder what is the shortest possible input field that can be used to perform a malicious XSS?

Depends on the context.

A very short one:

Context:

    <script src="%XSS%"></script>

Let's say you are the owner/maintainer/administrator of http://.to (Tonga gTLD).

    <script src="//to"></script>

XSS with 4 chars. Probably one of the shortest possible.

There are dozens of other contexts.

Edit:
Tested on Chrome 38.0.2125.122 (Mac OS X 10.8.5)


How to avoid fake "Windows Virus Alert" I was recently browsing online when I came across this page:

When I chose to close the tab, I received this message:

And after choosing "Leave this page" twice, I receive this message:

Choosing OK reverts back to the first message. It appears the only way I can close this tab is to force close Internet Explorer. I already know about scams like this; they show you your Event Log while declaring any errors are a sign of malware, then they talk you through installing remote control software, where they then talk you through handing out your credit card information, changing your log in password, and also doing god knows what else.

How can this type of hijacking be avoided? I am running Internet Explorer with Windows 8.

I would suggest using Firefox with NoScript or comparable setup.

NoScript allows you to monitor scripts loaded from websites and selectively allow certain JavaScript to run. That way you can avoid dubious scripts from running. It is especially useful as many malware is not hosted on the website itself , but often through ads or other third party content.

Other than that it is always a good idea to avoid shady websites, have AV product that is up-to-date, always install patches for your browser and OS.

In case you do need to visit websites with questionable reputation, you might want to use a VM with correct configuration to avoid infections of the host. This is not 100% secure but it is pretty good against average threats.

On the contrary of begueradj comment using NoScript prevents drive-by-downloads, when properly configured. Drive-by-downloads use exploits in the browser or it's extensions. Such exploits can be distributed through e.g. JavaScript, Java, Flash, Silverlight among others.
NoScript is able to monitor all content that is referenced and attempted to load by a website you are visiting. Such content can be disallowed and then is not loaded and of course not executed.
It also tries to protect against XSS (Cross-Site-Scripting), CSRF (Cross-Site-Request-Forgery) and clickjacking. Take a look at NoScript's website.

If you whitelisted a site that hosts exploits then of course NoScript cannot protect you (you allowed the execution of scripts manually). This is why you should also follow the other security guidelines.


Can Cross site scripting lead to database access? I wanna know that weather a site having XSS vulnerability can lead the hacker to access database? I know that he can get the username and password from the cookie stored but can he completely access the database?

XSS doesn't compromise the server, it compromises the client.

Basically, if your site is vulnerable to an XSS attack, then you're serving dodgy code to your users.  The attack has control over your users' actions, so has access to anything your users do.

So if your users do not normally have complete access to your DB, then an XSS won't give an attacker that access.

However, do bear in mind that "users" includes "admins", so the attacker has the power of an admin if one logs in while the exploit is active.


Can I find out if my employer is snooping on me? I work at a large university and have a computer supplied by my employer.

I would like to find out whether my employer is snooping or can snoop on my files or activity on my computer. Can I find that out? How would I go about?

There is apparently some sort of remote management that the help desk can use if I call them and accept their request to log onto my computer. Program updates are also pushed out automatically.

The machine runs Mac OS X, I have admin privileges and can install any software I want.

(Note that this is a technical question, not a policy one. Also note that I understand any computer can be hacked. This question is more pointed towards assessing typical threats from my friendly sysadmins and their equally benevolent bosses.)

The short answer is yes, technically speaking. They will have another admin account on the computer that they can access. By policy, though, access to this account is (hopefully) tightly controlled and will only be accessed if necessary.

Also, there is no such thing as your computer legally speaking if it is a work issued asset. They can look at anything at anytime for the most part with little or no justification needed. It's theirs and so is all of the data you put on it.


SSL Handshake takes much longer in LAN than in WAN Here is the structure we have, 3 servers in location A (172.22.25.X) and 3 servers in location B (192.168.140.X). One of the 3 servers in each location creates an SSL connection to the other 4 servers, like this:

A1 connects to A2, A3, B2 and B3 B1 connects to A2, A3, B2 and B3

When A1 connects to any of the servers, the SSL Handshake takes less than 300ms.

When B1 connects to A2 and A3, the SSL Handshake takes less than 300ms.

But when B1 connects to B2 or B3, the first time it takes around 9 seconds for the handshake to be finished. Following requests again take less than 300ms for a short while (a minute or two), and then back to the 9 seconds issue.

All 6 servers have the same software on them, running on the same OS (Windows Server 2008 R2 64 bit).

We tried all kinds of changes (enabling and disabling Windows Firewall, removing the antivirus software, changing the switch) but still the same issue continues, and we are out of ideas what it could be causing it.

Any ideas?

Usual suspects for overlong SSL handshake are rebuilding of certificate chains and CRL checks. A SSL client will validate the certificate from the server, which may entail obtaining the issuing CA certificate and/or downloading a CRL which covers the said certificate; both operations follow URL found in the certificates themselves. When a certificate has a local-only URL in it (e.g. an ldap:// URL which makes sense only in a given site), the relevant machine may need some time before noticing that the URL cannot be used, and, in particular, it may stall on a DNS lookup.

I suggest you run a network monitor tool (e.g. Microsoft Network Monitor) on both client and server, to see what happens during one of the overlong handshakes. This tool will be able to show you the individual handshake messages, but also other network activity -- DNS queries which fail after two or three seconds would appear there. (Knowing how a SSL handshake works can help; see this answer for a primer.)


Is there a way to safely exchange two different informations like a sliding door? In real life it would be like putting two items at the opposite sides of a sliding door, you turn it and they can be exchanged safely.

Not only that, if the door is made out of glass, you can pretty much guess that the other person either have the actual item you requested or put a considerable amount of effort to create a decoy.

How do you translate this in security jabba jabba?

I'm not sure what "security jabba jabba" is, but in terms of exchanging physical or virtual goods when your medium of communication is the Internet, typically exchanges like this are arbitrated by an escrow service, of which there are dozens.

There are certain special cases which can be automated in a fashion, but you'd have to come up with a specific usage case if you wanted more specifics.


If LDAP credentials are leaked, is IP whitelist still sufficient protection? In a situation where LDAP credentials get leaked but there is still an IP whitelist in place...

My gut feeling says this isn't right; the credentials should be changed. Is this correct? What technical details can help me impress this upon the concerned party?

There usually is a reason to use more than one way to protect services. Combining credentials with access-lists ensures that one of those can fail without having to deal with an immediate emergency.

That doesn't mean you shouldn't act when one of them gets compromised, why would you have bothered with implementing more than one if you don't care about them?

Technical risks you may have to deal with include misconfiguration of access-lists and IP spoofing. That's why you don't rely just on an access-lists.

However, in my opinion the bigger problem is that the operation expects more than one security measure to be implemented. Someone else may notice a misconfigured access lists and think 'no worries, you still need credentials to use the service'.

Bottomline: if you implement more than one security measure, you need to be sure you can rely on every single one of them. Having more than one just reduces the direct impact of one of them being compromised.


using temporary tokens for secure communication with IFRAME I have questions about our application's security architecture:

A critical piece that cannot save state but collects and displays sensitive information is served up in an IFRAME inside a more modern web framework that would control login, session, etc.

IFRAME app and parent are on same domain.  Both IFRAME and parent will use https.

When user logs in to the outer web application, an iframe-ed form containing sensitive information is generated and then made available inside and IFRAME via a unique URL  (e.g. hxxps://example.com/myapp/form/a8ba8b8dsf8sdfasfsd0sfd/) and immediately expired so that a subsequent request with the same url token cannot access the sensitive data.  Contained in the form is a one-time, time sensitive submit token (like a csrf token) that protects against unauthorized form submission.

I am thinking that the risk of a malicious user playing around with the iframe url is nearly non-existent due to the one-time tokens.

What security risks are there to this architecture?
Is there a better way for a wrapper app to communiate with the
IFRAME app?

I suppose the wrapper app could make requests directly to the child app and write the response straight out to its own page instead of using an IFRAME.  We would still need to generate temporary tokens because the resulting form would still need to submit to the "child" app that cannot maintain state.  The advantage to this is that now the wrapper application is the only host allowed to make GET requests to the "child" application  (the client must be allowed to make POST requests but those won't be able to get sensitive information).

This advice from OWASP seems to warn against this kind of thinking but the immediate expiration of each token seems to mitigate their concerns.

  Highly protected applications should not use URL rewriting to maintain state when cookies are turned off on the client.

UPDATE::::::

the wrapper app making direct requests to "child" app solution will not work for us and we are going the path of the IFRAME.  Are my conclusions about the IFRAME valid?

You can make the requests to the child app directly from the wrapper's server code and drop the use of the iframe. The child app should only allow access from the main application server.

This would also result in a better user experience, because you would have a better, uniform design.


Is SHA1 weak for SSL? I noticed that today after I scanned a site on the Qualys SSL Labs site that SSL ciphersuites which use SHA1 are now highlighted as being "Weak". It seems this has just happened; I scan sites pretty regularly and haven't seen this before.

We have all known for some time that SHA1 has some weaknesses. Does this change reflect some new problems with SHA1?  Has something officially changed in the industry to now have SHA1-based ciphersuites considered "weak"?  Or is this just something the Qualys site is choosing to do now?

Nothing has changed in the industry. Qualys is now just highlighting what we already know.

It is to give you a reminder that you should move away from SHA-1. It's not generally considered a critical problem yet, but should be sorted as part of normal refresh/update cycles.


Using Gmail in China triggered lots of Two Factor SMS A friend of mine lives in Hong Kong and she travelled to China over the weekend.  Whilst there, she was able to use Gmail on her Android phone without logging in again, but she had to re-login on her laptop to use her account (she didn't end up using it on her laptop).  Something very strange happened while she was there: she received 14 text messages on her mobile phone with the same 6 digit Two Factor login code.  She had never requested it herself.

What's going on here?  Are the apps on her laptop automatically requesting this Two Factor code to be sent?  Is this some sort of phishing attempt? Was someone (government?) trying to get into her account?  If someone was trying to get in, I think it means they already know her password or else they would not be able to trigger those texts.  She's definitely not a person of interest to the govt!

Am interested to hear thoughts on 1) What was happening? 2) What (if any) measures need to be taken now?

It is very likely that the SMS alerts were simply caused by heuristic algorithms on Google's end detecting a login attempt from a new location where past failed login attempts have occurred on a frequent basis. Why was 14 text messages sent? I don't know. Probably a bug on Google's end.

I wouldn't worry but contact Google if you want to clarify the situation.