My client needs credit card details emailed to them, will an encrypted file work? I have a new client who is a reseller for vacation packages. They have multiple wholesalers, and my client is instructed by the wholesalers to sign into their wholesale account, and enter their customer's credit card details on their behalf to book the trip.

I've personally confirmed this is their standard practice, and the wholesalers offer absolutely no assistance. The way my client handled this with their previous hosting provider was by having a simple form on their website, which their customers would use and the credit card info was sent via email.

This is bad, obviously.

To add to the mess, the wholesalers require the security code for the card.

I don't want to go through the scrutiny of PCI compliance, so I have a few questions:

Does anyone know of 3rd party service that this form could reside with? Also keeping in mind the CVV is needed.
What if I created an encrypted file that is emailed to my client upon form submission, and build a desktop app for them to enter in a key in order to decrypt it?
Is my business potentially liable if we build a solution and some how, some way, someone's credit card info falls into malicious hands? Perhaps I shouldn't allow it on my server and force them to get a new host, regardless if we do the work or not.

I just have absolutely no idea how to best solve this situation. Thousands of resellers of vacation packages around the globe, and this is what they're expected to do? I suggested to my client they take the card details over the phone, and shred it after making their payment, but they're unable to do this due to multiple reasons.

This has ended in a ton of searching and reading other scenarios. All the credit card "storage" services that I've found do not and will not store the security code.

I'm at a total loss. Please advise.

I believe the situation is a bit uglier than you may have realized.  Were I in this situation, I would invest myself in finding the wholesaler's competition!  I would want a wholesaler who provides either a service that can directly accept orders from your client's site or, better yet, a page that can be linked from your site to allow the user's to enter the information directly into the wholesaler's system.

PCI-DSS does not formally apply to your client except to the extent that the wholesaler requires them to comply.  You must understand that PCI-DSS is a contractual requirement between business entities.  It is not a law that everyone must respect.  You are not submitting the card data to a credit card processor, just to a merchant.  The wholesaler is probably in violation of its contractual responsibilities to its card processor, but that does not directly expose the wholesaler's clients (i.e. your client) to PCI specific requirements.

Having said that, the potential for legal action against your client by customers whose cc data is compromised may exist.  I am not a lawyer and this is not authoritative legal advice.  ALSO, independent of PCI, I believe every state in the US now has data breach notification laws that will require your client to notify customers of exposed data and provide credit protection for some period, usually at least 1 year, in the case of a breach.

So, PCI does not really apply, but you have to be careful how you handle all customer data. Now, let's discuss possible approaches.

Two encryption approaches suggest themselves: encrypt a file then emailing the file; using encrypted email using S/MIME.  Personally, I like the encrypted email approach.  An email can be constructed and encrypted in memory so the unencrypted data never lands on the server's drive.  Writing a file then encrypting it adds a layer of risk.

With S/MIME you will naturally use an x509 certificate with a public/private key pair for asymmetric encryption.  If you go with the encrypted file approach, I urge you to use asymmetric encryption rather than the much more simplistic symmetric encryption.  The big difference between the two is that an asymmetric solution on the web server would only hold the public key.  If the server were compromised, the attacker would not gain the ability to decrypt the messages.  Only your client, using the private key, could decrypt the messages.

There are several encryption solutions available.  One robust, mature and open source library is GPG.  It is also very well documented and versatile.  It could be used for either of the approaches I've described.


Is TLS_FALLBACK_SCSV useless if only TLS (1.0, 1.1, 1.2) is supported? Ssllabs does not give A+ (highest) rating if the server does not support TLS_FALLBACK_SCSV to prevent downgrade attack. But I am wondering, is it really any useful if the server legitimately provide support only for 3 latest versions of TLS? So downgrade will achieve TLS 1.0 at most which is kind of good enough anyway to support old browsers.

And more interesting if the server supports e.g. ONLY TLS 1.2 then this protection is completely useless, or I don't understand something in here?

The whole grading mechanism is more propaganda and public relations than actual security. If you want good security, then you must mind the details and understand how things work internally. If you want a good grade then you should do whatever it takes to have a good grade. An "A+" from SSL Labs is a very nifty thing to add at the end of a report, but it does not really equate with having rock solid security. Having an "A+" equates with being able to say "I have an A+".

The principle of the SSL/TLS handshake is that client and server advertise their maximum supported versions, so that the version which is selected is indeed the most recent that both client and server support. This property holds as long as active attackers cannot break immediately (in real-time) the handshake of any version that both client and server support. E.g. client and server can support all versions from SSL 3.0 to TLS 1.2 (TLS 1.2 is, internally, "SSL 3.3"), and attackers cannot force a downgrade because even the SSL 3.0 handshake is robust enough not to be immediately broken by active attackers -- and that handshake includes the advertised maximum version.

... Unless the client is doing something dumb, which is reconnecting and advertising lower versions than what they actually support. Existing clients do that because some must talk to servers that do something even dumber, which is crashing/disconnecting whenever the client advertises a version which is greater than the highest version that the server ever heard of. Normally, when the client says "SSL 3.42" and the server knows only up to "SSL 3.17", the server should answer "we'll use SSL 3.17". The standards and documentation on SSL 3.0 and later versions have always been very clear on that subject. But developers still got it wrong; some servers, when they receive "SSL 3.42", simply shrivel up and die on the spot.

Thus, in order to cope with possibly incompetent servers, clients have taken the habit to auto-dumb themselves in case of connection error. This is where TLS_FALLBACK_SCSV comes into play: it is an extra mechanism, smuggled in the handshake under the guise of a cipher suite, so that a client may tell to the server "btw I am not dumb, I am just sending a dumbed-down ClientHello in case you, as a server, would be one of these buggy server that blow up at incongruous times".

If a client applies the auto-dumbing and does not support TLS_FALLBACK_SCSV, then there is nothing the server can do to prevent a downgrade attack: attackers will be able to force the client to use an old protocol version by simply killing connections that attempt to advertise anything newer. However, if the client and the server support TLS_FALLBACK_SCSV, then they will detect any downgrade attempt.

This long preamble was only to get the context for answering your question. Basically, if your server does not support TLS_FALLBACK_SCSV, then active attackers will be able to force a downgrade, even if the client would have supported TLS_FALLBACK_SCSV. This is a problem in the sense that if you support TLS 1.0, TLS 1.1 and TLS 1.2, then this is for a reason: you prefer using TLS 1.2 when available, so if attackers have a way to prevent that, then this is, stricto sensu, a successful attack: attackers can force a situation that is distinct from the preferred, non-attacked one.

Now this does not mean that the consequences are serious. TLS 1.0 has a few known shortcomings, basically boiling down to two kinds of attacks:

BEAST-like attacks that use chosen-plaintext to leverage the fact that in TLS 1.0, with CBC-based cipher suites, the attacker can predict the IV for the next record;
Padding oracle attacks relying on, for instance, small timing differences in the treatment of incoming records (described as the "Lucky 13 attack").

TLS 1.1 fixes the first kind, with per-record unpredictable IV; for the second attack, TLS 1.2 offers AEAD cipher suites that do not need padding at all, thereby avoiding any padding oracle. However, both kinds of attacks can be efficiently mitigated in "pure" TLS 1.0, by using the "1/n-1 split" for CBC-based cipher suites, and with constant-time MAC computation, respectively.

Thus, if the client is sufficiently well developed to do a 1/n-1 split, and the server is sufficiently well developed to compute MAC in constant-time, then using TLS 1.0 incurs, as far as we know, no security issue that would need fixing. It may be argued that a client and a server that implement TLS_FALLBACK_SCSV are necessarily recent and "probably" up-to-date with implementation recommendation, so chances are good that they will do everything correctly and be able to run a safe TLS 1.0.

However, there is always a nagging suspicion that a server that supports TLS_FALLBACK_SCSV might support it only to get an A+ from SSL Labs, and may have not taken the effort to do constant-time MAC computations, because SSL Labs cannot readily test for constant-time computations.

To sum up: not supporting TLS_FALLBACK_SCSV is not necessarily a serious issue, depending on how well the client and server implement TLS 1.0 (by not supporting SSL 3.0 you already avoid the most glaring problems). However, good implementations cannot be guaranteed, and not supporting TLS_FALLBACK_SCSV is formally a weakness, even if it is not necessarily a vulnerability. That the weakness cannot be turned into a full exploit by attackers does not mean it does not exist.

In any case, you won't implement TLS_FALLBACK_SCSV because you want security; you will implement TLS_FALLBACK_SCSV because you want an A+. If you do not, then you will spend inordinate amounts of time explaining to many people that the "A+" grade is meaningless in that respect and that you can afford not to take it. In the long term, not howling with the wolves is too expensive.


What are the privacy implications of using Yubico OTP with YubiCloud? I am considering purchasing Yubikey devices (made by Yubico) to add two-factor authentication when my users ssh to our various servers.  I figured I would configure the device to use Yubico OTP with YubiCloud (via the yubico-pam PAM module).

What are the privacy implications of doing this?  Will Yubico know which users are logging into which servers and when?  The OTP value includes a static identifier and the server would query YubiCloud the instant the user hits the button, so it seems like Yubico could track users as they log into various servers.

Is there anything I can do to minimize any privacy leaks?  For example, can I configure my ssh servers to first try a local validation server and fall back to YubiCloud if the local validation server is unavailable?  (I would want to set up some form of synchronization with YubiCloud to prevent OTP replay attacks, but I don't know if that's possible and the synchronization might negate the privacy gains from running my own validation server.)

Yubico will not know, which users are logged in. The yubikey only sends a serial number within the otp value. They use this serial number to map the AES key.

So it is not anonymous but pseudonymous. If they ever would map the identifier/serial number to the user, they know it.

But (tin foil hat mode)
yubico may know which serial number they sold to you. So yubico knows, that someone of your company is logging in. They also might know this from the requesting IP address.
Then they could decide to say aye or nay, not depending on the real presence of the yubikey but depending on if the FBI wants to login or not ;-)
(tin foil hat mode end)

If you worry about this you can use privacyIDEA running on premise to validate all your OTP devices (in HA mode).

PAM is a mighty stack. You can configure everything you wish to. So you could configure a local authentication instance and fallthrough to the cloud service. But as mentioned above - you can also configure your local service in HA.


PCI DSS Compliance for Client I'm new to PCI DSS. I'm coding a custom WordPress plugin for a client of ours which shows a form on their websites. This form will take the customers name, email, quote number, amount, and card details. When they submit the form, a script will send that info to the NetPay API, which will process the transaction and return a status code.

Can someone advise on what PCI stuff we as a business, and the client should be aware of?

I've been direct to the NetPay site, the PCI site, various other provider sites but none of them answered my question really. From what I can see as they're a low transaction (qty) business, they'd need tier 4, but seeing as we're using the API, not a hosted form or anything to do it, it might be different. Please note we're not storing ANY card details, and we will have SSL. Edit: We're also hosting the site through OVH's network, however due to it being API based I imagine the server will need to be in a PCI DSS compliant data centre too...

Thanks in advance folks,
Ash

If your e-commerce site neither stores, processes nor transmits PCI data, then you can take what is known as Attestation A. This is what you do when you use a so-called "Payments 2.0" provider, such as CyberCash, etc. Some providers host the form for you, others provide a POST API, or both.

Who hosts the capture form is not so important, but where the POST goes to is -- if the capture comes to your site, you cannot take Attestation A.  If it goes to CyberCash (or whoever), you can... since the PCI data never touches your site or your database. In this case, the User's browser transmits directly to the payments provider, not you.

Nevertheless, you still have to engage a QSA to verify your Attestation A eligibility.

Example form: https://www.forte.net/images/Sample_SAQ_A.pdf


Issues/Vulnerabilities that TPM 2.0 aims to enhance/solve comparing to TPM 1.2 I have read some documents that comparing TPM 1.2 and TPM 2.0 (e.g. more supported algorithms like SHA-2, reduced code size, or even symmetric keys seems added, etc.)

I want to ask that what are the objectives to develop a non-compatible TPM 2.0? Actually in other words, what are the key issues that TPM 2.0 aims to solve / enhance by comparing to TPM 1.2? (just like TPM 1.2 solved vulnerabilities in TPM 1.1.)

E.g. solve the vulnerabilities that existed in TPM 1.2, enhancements to prevent certain attacks, support more algorithms so fit more platforms, etc.

(Another small question: after TPM 2.0 become mature, what could be the possible trend of TPM 1.2, replaced?)

The UEFI made a small presentation describing why we need to get to the TPM 2.0 and forget the 1.2.

First the SHA-1 algorithm is considered unsafe, and as they say, just jumping to SHA-2 is not long-term efficient. So TPM 2.0 supports in theory every kind of hash algorithm. Here is the NIST's policy on hash function. SHA-1 should not be used for any cryptographic uses. (as forest said, sha-1 is only weak against collision, using SHA-1 with HMAC is not really impacted)

Considering the asymmetric cryptography, the RSA is not so much obsolete(while we stay with decent length keys), but maybe one day, the problem of the integer factorization will not be a problem anymore thanks to Shor's algorithm. We need to have any kind of public-key cryptography. So there are all the Elliptic Curve Cryptography algorithms, the discrete logarithms algorithms, and obviously the Integer Factorization.(Apparently, the elliptic curves should be more vulnerable to Shor's algorithm). Before TPM 2.0, the only choice we had was the RSA. The available algorithms depend on what the vendor wanted to implement.

Finally considering the symmetric cryptography, with TPM 1.2 we have the XOR and especially AES. There is no known attack against AES, but having the choice is nice. There are alternatives to AES like Blowfish. And there must be some kind of political choices(AES is approved by the NSA, some people/countries may think this is a bad indicator: « If the NSA approves it, they must know how to decrypt it »)

It is supposed to be easier to use. I will quote the UEFI presentation :

  Removed the confusing
  enabled/activated/disabled/deactivated
  states
  –
  It’s either there or not there (ACPI table)
  –
  If present, it can be used by firmware even
  if not exposed to the OS

Finally, TPM 2.0 contains 3 permanent hierarchy keys (Platform, Storage, Privacy) against only one for TPM 1.2.

The Privacy hierarchy uses the endorsementAuth and can be used to generate EK(endorsement Key just like in TPM 1.2), and thus generate easily AIK(Attestation Identity Key), which can be used in Direct Anonymous Attestation(Authentication with a Zero-Knowledge Proof)

The security hierarchy uses the ownerAuth and is used to encrypt/decrypt datas.

The platform hierarchy uses the PlatformAuth and can be used to initialize the TPM, and enable/disable the use of the other hierarchies.

So basically, with 3 hierarchies instead of 1, you can do the same thing, but the authorizations are more clever.


Deanonymizing users by introducing structured delays to the network? Here is a scheme for deanonymizing a user that I've been thinking about, just out of curiosity. I tried searching for it but didn't find much. Does this technique have a name? Are there any papers or articles on this? And is it known to be in use?

So a user posts a lot of information, on Twitter or on a Blog, etc.. He/she tries to be anonymous by using internet cafes, Tor, proxies, or any other method. The user's posts obviously don't have geotagging information, but they have precise timestamps.

Now, an attacker could introduce slight delays into all potential user's connections, of the order of milliseconds. They either do this with the cooperation of the ISPs (e.g. intelligence agencies), or by spamming the connections using botnets (e.g. criminals). The attacker would vary the delays by location and time. Then, looking at the timestamps of posts, there would be windows where a targeted user would be less likely to have successfully submitted a post. A simple example, if I imposed a delay of 2 seconds at 9:00, the user couldn't have posted at 9:01. In real life, the attacker would probably use tiny delays and a lot of posts, and use probabilistic methods to narrow down the target.

Ways to improve accuracy would be to get more precise data (getting the exact timestamps of posts by cooperating with the sites the user posts to), or by watching a real-time stream of data, e.g. VOIP, and correlating the delays with the imposed delays.

Now, thinking about it, you could possibly even do this passively, by measuring latency at a lot of points and correlating it with the timestamps of your target, but that makes it at lot harder.

So, would this work? Is this known to be used?

This is a timing attack and the idea (including defenses against it) has been the subject of several academic papers.  The short answer to your question of "will this work and has it been used?" is "yes".  Some anonymity tools / networks (not sure if Tor does this) introduce their own latency and fake packets to make it harder (see "dependent link padding").

On the Effectiveness of Low Latency Anonymous Network
in the Presence of Timing Attack

How Much Anonymity does Network Latency Leak?

Impact of Network Topology on Anonymity and
Overhead in Low-Latency Anonymity Networks


How to avoid GAE app traffic being abused? I am going to develop a simple CMS site on top of Google App Engine using webapp2. I am wondering how avoid malicious data scrapers to deliberately get the pages in order to make the app consume traffic beyond the free quota (I think 1GB per day) and hence cause Google to charge me for the junk traffic. Thanks

There are two types of automation that you should be concerned with in regards to automation.

On one side of the coin there are search engine spiders that will pull down whatever they can,  you can direct these spiders with a robots.txt and sitemap.xml.  Which is a simple problem to solve.

On the other side of the coin there are the (very uncommon) content scrapers.  These are virtually indistinguishable from search engine spiders.  They often use the same user-agent,  and use about the same amount of bandwidth as a search engine spider becuase they both want to be up-to-date.  To find a spider that is breaking the rules you could specify a blacklist request handler in your robots.txt,  and if anyone hits that page,  you could ban them.   Although,  the number or malicious spiders is very, very small,  and this could be leveraged as a CSRF-DoS attack,  whereby an attacker forces a victim into loading the blacklist request handler.

...  that being said 1GB is TON of text,  and its very unlikely that you would go over this limit unless you where the victim of a DoS attack.


How might one verify that the POWER9 CPU does not contain an AMT-style subsystem? Given that the IBM POWER9 CPU doesn't appear contain an AMT subsystem (like those seen in Intel and AMD CPUs), is there any way the absense of such a backdoor could be audited?  For example, might a lab be able to physically disassemble the chip to verify that it matches an open spec?

A lab could theoretically decap the chip and analyze it, and any large, complex subsystem inside would not be able to hide from that (although you could not verify that it matches the open spec). If there's something undocumented that functions as an actual backdoor, then it would, by definition, be hidden. There are endless possibilities for embedding a backdoor in a complicated architecture like POWER9. For example, setting a couple registers to magic values that are unlikely to be guessed or occur naturally and then running a particular unprivileged instruction could trigger the elevation to supervisor mode. It could even be designed such that vulnerabilities worse than Spectre and Meltdown are "accidentally" possible, providing plausible deniability in the backdoor.

In regards to the specific capabilities of the CSME or AMD PSP, you can verify that POWER9 lacks a few of those features. For example, the CSME has access to many network cards, and to the on-board gigabit Ethernet system (Intel GbE). This requires the PCH be hooked up to the network card in a particular way that may be unique to the x86 architecture. You should be able to verify that, for example, the CPU cannot directly control the network card in any way that is not possible through the interfaced used to connect to it (e.g. PCIe). You should familiarize yourself with the system's architecture, as it is quite different from systems that descend from IBM-style x86 PCs.

While I don't know if the AMD PSP can do this, server systems with AMT can keep the coprocessor powered up even when the system is off, as long as it is connected to the power. It is trivial to detect if this is the case with an arbitrary computer by measuring power draw while the system is off. It is trivial to verify if any coprocessor is exposing itself automatically to the network by seeing if the networking card has a new MAC address. This assumes they are on by default.

But what is the actual risk? I would say it is very low. AMD PSP and Intel CSME are designed to make the lives of system administrators easier, even if they come with security downsides. As such, it makes little sense to keep them secret and undocumented. The only reason they would be secret is if they are an intentional backdoor, in which case they need not manifest themselves as coprocessors, and could instead be implemented as a simple but fatal security "bug".


Why would you not permit Q or Z in passwords? Jetblue's password requirements specify that, among other stringent requirements:

  Cannot contain a Q or Z

I can't fathom a logical reason for this, unless it were say, extremely common for the left side of keyboards to break, but then you wouldn't allow 'A' either :)

What would be the reason for this security requirement?

It's a leftover from the time when keypads didn't have the letters Q and Z. Security-wise, there's no reason. It's just because of old systems.

To clarify:

You used to be able to enter your password over the phone. Some phones didn't have the letters Q or Z, like the one on the picture below.

  Image courtesy: Bill Bradford on flickr.com

Because of this, passwords including these characters were disallowed. They haven't changed this requirement for whatever reason: Legacy systems, poor documentation, or they just don't care.


Does NAT really provide security? I had an argument with someone on IRC about Network Address Translation. I was under the impression that NAT provided a layer of security to internal networks. I understand that's not the primary purpose of NAT, nevertheless, I can't really see how I could be wrong about that. Anyway, I got laughed at and mocked over it but never really got a straight answer as to how or why I was wrong. So does NAT really provide security? Or not?

NAT is often misunderstood because in todays "office routers" there is as good as in every case a combination of NAT/PAT and a firewall which isn't the same. Also when you say NAT most people really mean NAT/PAT which is a combination of Network Address Translation and Port Address Translation.

This means that the router which is providing NAT/PAT functionality is able to map a specific port on the external network to a specific host on a specific port in the internal network. This can provide some extra security by lowering the attack surface of the servers that otherwise could be scanned and attacked directly. Of cause the forewarded services can be attacked anyway...


What are the dangers of exposing weakly protected user accounts bound with a fake shell over ssh? As anyone running a server can tell from first-hand experience, there are bots trying to constantly brute force their way through with commonly found usernames over SSH.

A friend of mine created a number of accounts with these common usernames (with the exception of "root"), gave them extremely weak passwords, and attached them to a fake shell. The fake shell is not functional in any way: it just displays some canned responses resembling a very broken system, and logs the user-entered commands into a file.

Assuming that this fake shell does not have any security vulnerability by itself, what could be the possible dangers of such a setup?

this fake shell does not have any security vulnerability by itself

... is usually the wrong assumption. I played with this idea some time ago, but I didn't find any reason why to do such a thing.

It might be interesting as a research of hackers/bots behaviour, but for that you have already existing solutions, that should be more appropriate and probably more secure and give you more data. Also if you want to play with honeypot and observe hackers, there are few assumptions you miss:

root is the most common target. Attacking on different users gives the attackers less possibilities to exploit. Giving up this account (either securing it well or disabling the login) you loose a lot of possible data.
Even simple passwords might be hard to guess in combination with common user names. If your use case is above (watching hackers/bots), than you might get really few data from such setup since most of the scans fail.

And few bits to your question:

your accounts might be exposed to different services, where they might be misused, for example SMTP to send SPAM through your server
the security of the shell as mentioned in the start once more and access from it to any resources (files, network, system calls, ...)


What are the security implications of my credit card number being known by someone else? I am new to the credit card world. What are the security threats or possibilities, if someone knows my credit/debit card no. Will he be able to misuse it or will he require any additional information related to the card?

An excerpt from another answer:

  You don't actually need the CVV to perform transactions, they're just required by most retailers as a means of verifying that you have the physical card in your possession.

  From Wikipedia (unsourced):

    It is not mandatory for a merchant to require the security code for
    making a transaction, hence the card is still prone to fraud even if
    only its number is known to phishers.

  On most EFTPOS systems, it's possible to manually enter the card details. When a field is not present, the operator simply presses enter to skip, which is common with cards that don't carry a start date. On these systems, it is trivial to charge a card without the CVV. When I worked in retail, we would frequently do this when the chip on a card wasn't working and the CVV had rubbed off. In such cases, all that was needed was the card number and expiry date, with a signature on the receipt for verification.

In other words:

You could use that number to make payments or purchases in some systems. But if they have also your CVV from the back of the card your card is fully compromised and can be used for all kind of payments.

Recommendation:

Contact your credit card bank or issuer. They can provide you a new credit card. Also CC are something pre-internet they don't have an amazing security and every bank in this world actually prefer to be like that because they can follow the money transaction and they can find who is the responsible for a CC fraud.


Did I stumble upon a cell hidden network or is my device being attacked? Sorry for the somewhat vague title, it is hard to explain without the pictures as the network I connected to is Chinese (I believe). Note the cell signal in the top left corner and the name of the network carrier it is connected to.

I have AT&T as my service provider, and roaming is off. I have never seen this and am at a loss what this could potentially mean. I noticed this during work and the name and signal changed only for about 20-30 seconds before changing back to AT&T. Is this a potential and real security threat to me and potentially my coworkers? Should I notify someone in IT security of my findings?

iPhone 7 MN9N2LL/A
iOS 11 build 15A5318g
AT&T Prepaid Service

I strongly suspect those four characters are an "A", a "T", an "&" (the Sun symbol) and a "T" again. Possibly the UTF8 for 4F10, 5418, E298BC and 5418.

Actually, as @Matt observed, the little-endian UTF16 sequence 4100 5400 2600 5400 ("AT&T"), if interpreted as big-endian, becomes 䄀吀☀吀 which closely matches the strange logo that appeared in the cellphone.

Possibly whatever packet contained the carrier "logo" got corrupted, CRC notwithstanding, and was interpreted as a foreign character set.

Update:
Two users added comments (unfortunately posting them as answers, which got them deleted) confirming that this happened to them; in one case on September 29th and 30th, "several times [...] traveling through North Dakota, Minnesota, Wisconsin, Illinois and Indiana... usually when AT&T signals were weak."


Common passwords among servers/web sites on a development platform I have been involved in a discussion about the use of a standard user name and password within a development environment and would appreciate comments:

The single development server holds a number of linux-based database and Web servers - one pair per customer project. There's a single instance of PostgreSQL holding multiple customer tables, and a single Web server (Apache or NGINX) hosting multiple Web front-ends. The data in each customer database table is obfuscated and anonymised and the Web front ends for each customer are associated with a specific database table to make up a working site. This entire setup is only available to in-house devs and also to a third-party testing company via a secure VPN. At the end of development, the site database structure and Web customisation is moved to a separate customer-facing platform and loaded with real data for the customer to test. These new platforms are always built from scratch and no development user names or passwords are transferred.

On the in-house development platform, the devs want to use a common user login/password for the Web sites, and ditto for the database accounts and linux root user, arguing that this makes life easier as they move from site-to-site during development and there is no customer-sensitive data anyway.

At a simple level, having one set of accounts for everything makes life easier, but how would this go down against formal (UK) infosec standards, and other standards such as ISO27001? Can the use case and environment make this acceptable, or would this go against the grain of formal or informal guidelines that you should have unique account details for all accounts you manage and never share passwords?

In other words, how would this setup be viewed by a formal security audit?

Thanks

While they may be difficult to avoid, shared accounts are generally a bad idea for information security and are not looked kindly on by ISO27001 or security auditors.

Shared accounts make it difficult to create a proper audit trail, as actions cannot be directly linked with a real person. There are, however, ways to get around this, for example by implementing a tool to manage and track the use of the credentials.


Mobile phone security eavesdropping based on data transfer is there an easy way for particular governmental organizations (especially in
countries where freedom of speech is a problem) have some technology where
they can easily eavesdrop on cellphone internet data and parse it in an easy
fashion like, running a simple app and recording a plaintext version of the
transferred data?

For example you type about, let's say a chat app over the phone, is there an
easy way the government could directly spy on you and FILTER out the plaintext
of the application? (If you think that apps like wireshark can filter out packets
very easily, is that kind of think possible for cellphones too?)

Please try to answer as broad as possible.

Thank you

Yes. The easiest way is to get or force the mobile phone carrier to provide unencrypted access to a mobile switching center. At this point identifying and interperting packets and the data the cary is exactly equivenlent to using a packet sniffing tool like wireshark. Given the limitations of cellphones and smartphones it is easier to identify the applications generating data traffic.

Recognition of plain text words or phrases is trivial and a monitoring for target words or phrases is likely. It is also possible to intercept Voice over IP data traffic and perform a speach to text conversion, although this would be significantly more complicated and take a fair amount of resources.


With SSL/TLS, is pre-sharing of a certificate fundamental to avoid an initial active MITM? First, I have some conceptual questions, and then some more specific questions with regards to implementing HTTPS.

In an extremely simple system with only 2 hosts (A and B) talking on a LAN but an active MITM on the the LAN (Z), who is active from the very beginning and able to intercept and fully modify first connections between the 2 hosts A and B, it is true that fundamentally, some piece of data must be shared out-of-band to avoid this attack scenario, correct?
In other words: there is no algorithm, protocol, or mathemagical trick that exists that would allow host A to connect to B for the first time ever, having absolutely no prior knowledge of B, and somehow assert that B is not a MITM, correct? I know this question might sound obvious, because truthfully if A has no knowledge of B whatsoever, then there really is nothing distinguishing B from Z to A, but I need to hear it from the experts.

This is exactly how PKI on the internet works, right? Because a server's certificate is signed by a CA's private key, but the public certificate of the CA was effectively shared beforehand, and in an out-of-band manner (when you purchased the computer, or OS disc, it was already in the browser software).

Is it also true that a CA issued cert in comparison to a self-signed cert only provides a logistical benefit in the form of scalability? (in comparison to a hypothetical world where all parties shared certs securely, out-of-band) In other words say every site on the internet attempted to use self-signed certs, then technically it could still be secure if for example amazon.com and I communicated out of band and amazon shared its certificate (in a way that I could establish trust that the provided cert was actually amazon's), so I could validate future connections, right? But the problem would be needing to perform this out-of-band step for every website out there.

Now onto a related implementation problem.
Picture a hypothetical self-contained computer system with roughly 100 hosts on a private LAN.  1 host is the "master", and is initially installed manually (from a disc, drive, or some other trusted physical media). But the remaining 99 hosts are installed over the LAN (https).  If the remaining 99 hosts have no persistent storage and install directly into RAM and begin executing, then it must be impossible to design such a system to avoid the initial MITM possibility described above, right? Especially considering each of the 99 hosts does a full re-install, and essentially connects for the first time on every reboot. Because there is no place or means to store any kind of pre-shared certificate or validation data so that the 99 clients can digitally verify an SSL certificate presented by the "master" server.  And if there is no out-of-band method of communication, then they must resort solely to initially accepting the certificate over the same connection (creating the MITM possibility).  Additionally, the 99 hosts are automated, so there is no possibility for a user to intervene, and validate a fingerprint, like with what SSH does.  But this would really just be another form of out-of-band communication it seems.

For the points 1..3: Yes, that's how it works. There is some initial trust needed, either in the form of a trusted CA which can be used to derive trust into leaf certificates or as directly trusted shared leaf certificates.

As for your implementation problem: I assume that your disc less clients have same sort of read-only medium they boot from because otherwise your trust problem starts earlier, i.e. how they make sure that they boot the correct OS when booting from a network. Thus assuming that the OS they boot is in fact the correct one but that they have no knowledge of who they can trust they have to rely on "TOFU", i.e. Trust On First Use.

Of course one could try to put at least some initial trust information in the systems because even weak trust might be better than no trust. For example each of these system could come with a different certificate installed by the manufacture, all signed by the manufactures CA. This way one could kind of assure on first connect that the peer device is at least from the manufacture and thus make attacks harder. This is not foolproof of course since the attacker might be able extract the device certificate and key from an existing device or modify such device to work as MITM but this way the initial costs of the  attack would be higher.

BTW, this is not a problem restricted to TLS or even to computers but it is a simple question of what information are needed to trust somebody. And if you have no information at all you have no way to decide if communication peer is trusted or not. That's the reason you have various forms of centrally issued identification in real life, i.e. passports, driver license or similar which provide you with a way to derive trust because you somehow trust the issuers of these ID cards.


How are apps on the Play Store infected by malware? I just read about the Xavier malware that has apparently "infected" some apps on the Google Play Store.

As usual when there are news like this, they dumb it down to a level that most people can relate to, using terms like "infected with" etc. Some newspapers make it sound as though there is a virus running amok in the Play Store, "infecting" apps one by one, which I find highly unlikely! The article I linked to does seem to indicate that the malware is actually a third party ad library used by the affected apps.

I'm a developer myself, and I don't really get how an app could be "infected by" a library. A library is something you actively choose to include in your app because it provides functionality that you want. Do they mean that the library maker purposely included malicious code in their ad library, or was the library somehow "infected" by some unknown actor?

Here is a link to Trend Micro's analysis of it.  Looks the library is intentionally used in the apps rather than them being "infected".  I think the apps' primary purpose is to deliver the malware.

From the article, the thing that jumps out at me most is the following: "...it comes with an embedded malicious behavior that downloads codes from a remote server, then loads and executes it. Second, it goes to great lengths to protect itself from being detected through the use of methods such as String encryption, Internet data encryption, and emulator detection."

Three things that make it dangerous: 1.) It can encrypt the traffic between it and it's command & control servers. 2.) It can download and execute code from said servers. 3.) It evades detection. The fact that it can remotely download and execute code (think: updates that change it's behavior), encrypts it's traffic so no one knows what it sends back, and tries to evade detection tell me that it is designed to do something more nefarious later

http://blog.trendmicro.com/trendlabs-security-intelligence/analyzing-xavier-information-stealing-ad-library-android/


What are the security flaws in web based TOTP app? If there is a widely accessible TOTP website (prototype: https://depperm.github.io/) that allows users to set a date and secret they can remember or a package that allows companies/developers to create their own domain/site specific tool, what possible security flaws are there beyond having information phished, key logged, or copied in person?
The date and secret would be stored encrypted on the database (and set in the same manner as a password), so when the OTP comes in a new token can be generated from the decrypted info and validated against the incoming one.
I am aware of the potential issue of client time being different than server time, but I believe there a viable solutions for this problem and I don't see it as a security flaw but a usability flaw

what possible security flaws are there beyond  having information phished, key logged, or copied in person

Does one really need more problems on top of these? Basically it is asking to enter critical information into an untrusted third-party site. Untrusted means here both that one cannot trust the third party to not have shady intents nor that one can trust the party to not being hacked and backdoored - since such site would be a very valuable attack target.
Apart from that what you describe is basically a black box similar to a software app and a hardware token, i.e. the specific implementation is not clear and thus one cannot point out specific implementation problems. Compared to existing approaches it is kept online though, which might provide a use DoS attacks to make it unavailable. If users rely on it to provide their authentication tokens this essentially means to deny authentication for the users.


How to verify if SSH Client is not recording my login information? there are lots of SSH Clients one can use with Android, for example JuiceSSH client, so i have a security concern, that is, how can i know or verify, that this app is not recording my credentials to when i authenticate to my server?

It is hard to verify that your login information is not being transmitted to third parties. A malicious application could choose to share your credentials directly (or at a later moment) with an attacker (possibly in encrypted form).

Possible solutions or mitigations:

Use an opensource SSH client such as ConnectBot, the source code is available so you could audit it or build it yourself.
Use SSH keys instead of password-based authentication. While an attacker can also copy the private SSH key to a third party, revoking a SSH key should be easier than changing and remembering a new password.
Trust on the (number of) users and reviews of the product, check the background of the author.


Risks with OpenSSL verifying a signature with un-trusted PEM encoded public key If a website user wants to use WebAuthn, they will start by creating a credential, where their authentication device provides a public key.

This key is encoded, and sent back to the server to store against their account.

Later, when the user needs to be verified, the website provides a challenge, their authentication device signs it, and that's sent back to the server.

Assuming PEM encoding of the public key (originally sent to the server from a potentially hostile user), are there any risks with this?

Is it possible to cause a Denial of Service?
Could it cause OpenSSL/PHP/Apache to crash?
Use up too much memory, or take a long time to process?
Provide a key format that OpenSSL does not understand, or get confused by, and return an unexpected result?

Some example questions I'm unsure about:

If it's an Elliptic Curve (e.g. prime256v1), could it include excessively large x/y values?
Is there a problem if a DSA key was provided?
Is there a problem with an RSA key using PKCS1v1.5 padding?
While RSA is normally 2048-bits, what happens if it's a 65,536 bit key?
What about invalid DER encoding (e.g. wrong field lengths)?
How about an invalid DER Object Identifier?
Could invalid base64 encoding of the PEM data cause issues for OpenSSL?

I know a normal user would not do any of these things, and I accept that anyone who does provide a flawed public key would be affecting their own account, but could it cause other problems?

This is a basic implementation in PHP:

<?php

// PEM encoded public key, from hostile user
$key = '-----BEGIN PUBLIC KEY----- [...] -----END PUBLIC KEY-----';

// Other checks

$verify  = base64_decode($response['authenticatorData']);
$verify .= hash('sha256', base64_decode($response['clientDataJSON']), true);

$signature = base64_decode($response['signature']);

if (openssl_verify($verify, $signature, $key, OPENSSL_ALGO_SHA256) === 1) {
    // Success
}

?>

Note how openssl_verify() takes 3 values that came from the user.

And I could use openssl_pkey_get_details() to check the type, curve_name/oid, and x/y values.

In short, should the server be doing any additional checks on the public key?

It seems like you're question boils down to two concerns: Can a logic flaw in your code be exploited? And Is the process efficient enough to not fall over under mild load? The concept itself doesn't seem unreasonable for a web server to accomplish, but if you're worried about the processing load, you can have the web server and php processor reside on different servers (or even put them on clusters of servers, with load balancers, queues, and caching layers, there's a real bottomless pit in the pursuit of high availability). But bear in mind that avoiding DoSs and app server crashes is a hard problem. The best we can do is make it hard/expensive for attackers to knock your server(s) over.

Limit the size of POST requests

Have the web server limit the size of post requests to limit the impact a single request can make. Here's an example using httpd .htaccess file

Check return codes

I see you're checking openssl for errors, you should also check the return code for base64 decode and make sure that operation succeeds, before passing garbage further on in the pipeline.

String size

I'm less familiar with how to do this in php, but setting an explicit max size and throwing errors if the input is larger or only handling a truncated version of long inputs.  But if a malicious user sends a 1GB block of text, at a high rate, and you are running expensive hashing operations, your server might get knocked over. But if you curtail it to a max size of 100kb before sending it to be hashed, you'll be doing better.

Regular Expressions

I'm a proponent of running user input against a regular expression before processing it (i.e. making sure the supposed base64 data only contains [A-Za-z0-9-/\=], though you may have to URL-decode it first. A regex expects to to be passed arbitrary data and most regex libraries can handle binary data, however, a base64 decoder might not expect characters outside of the 64 character set. However, a regex engine could also be compromised, so your mileage may vary. Also, worth considering, regexes are expensive in terms of memory and CPU, so it may actually make it so that your application can handle less requests.

I wouldn't bother doing much validation of the blobs that come out of the base64 decode. Openssl probably has a safer and more correct implementation that anything you homebrew, so long as you...

Patch your dependencies

The openssl library, the base64 library, and anything else in the critical path of parsing user input should be on an aggressive patch schedule (balancing the risk of downtime if you deploy without adequate testing). This includes the php engine, web server, and the operating system kernel. Because most known vulnerabilities will be patch within days, you'll only have to worry about zero-days, which is largely out of your control.

Infrastructure Layer redundancy

External to your question, you could also use a CDN, load balancer, or a WAF to protect against certain attacks or floods. Having a dedicated SSL Terminator can reduce the load on a webserver. Also, rearchitecting your application to operate in independent tiers (or tiers of clusters) can limit the blast radius of a crash and can help you address load. Using a geolocation-based sharding/routing algorithm in a distributed web app can make it so an attacker from a single IP could only DoS other users routed to that shard, so you can ensure, for example, that 67% of users will be up if you have three shards. Botnets can sometimes be addressed by WAFs. This is a huge rabbit hole that probably spans beyond the scope of your question, but hopefully gives you some ideas of directions to look.


Data needed for ISP to identify users If the following data is known:

URL of web site X,
Exact time and dates when the visit to web site X occurred,
Anonymized IP address of web site visitors (without the last digit, e.g. 125.251.101.x),

can ISP still determine/identify users who used its network to visit the web site X in given dates and times only based on this information or it needs the complete IP address?

To identify its client the ISP normally needs its full IP address. But... they may have their own logs. In fact, depending on the country, they may have to keep logs for some month in case of legal investigation.
In that use case, knowing the dates, and the destination site should be enough by comparing that information with what they have in their own logs (exact IP, date and destination). Once the exact IP is identified, they know which client is responsable, and can (must) give that for the legal action.


Is it safe to use jku, kid and x5u in JSON Web Signature (JWS) header? I don't get what header parameters like jku, kid, x5u are for in JSON Web Signature (JWS).

Since We have to verify the integrity of the content against secret key/public key, is it safe to leave jku, kid, x5u in the JWS header? Someone may replace these sections by their own and sign a new signature with his key against the tampered content. So how do we deal with such case?

These fields are here to allow the component verifying the ticket to identify the key used for the signature.

jku is an URI that reference the public key used for generating the signature. It must follow RFC7517 format. The entity verifying the token is responsible for checking whether that signing key can be trusted or not.
kid is the key identification and it's only valid in the context of a given audience: the context of your application must define how to use that parameter to identify the key. It can be the fingerpring of the x509 cert user for signing, it can be the certificat serial number, it can be a reference to a row in a table, it can be the ID of a HMAC secret stored into a JSON file, or the XPath inside a XML document, whatever is defined by the signing party.
x5u must contain an URL to the x509 certificate that was used for signing the token. That certificate must be in PEM format.

Typically, you will only have one of these parameters in any given token (there can only be one signing key, after all) although it isn't impossible to have the same key accessible through different methods (this mostly means that it's not impossible to have both a jku and a x5u header that point to the same key but you should try to avoid that kind of ambiguity).

By definition, if someone changes the headers and signs the ticket again, the result is not the same token so you don't need to worry about that: you can safely reject any token that you can't properly validate.


Should usernames be kept secret? Help me settle an discussion among colleagues and guide future design:

Even in a high impact scenario: e.g. protecting payment application or government gateway but in an Internet accessible application

Is it worthwhile implementing any of the following (or other) measures to protect a username:

Requiring a complex system generated username like the UK government gateway or HSBC on-line banking? Is the trade-off in terms of users forgetting this, needing to write it down, the additional call center traffic, users having to self service username reminder worthwhile vs the risk of using a public username such as email address or mobile number?
Providing a generic message: "your username or password was incorrect" instead of more user friendly "your username was not recognized" and "your password was incorrect"
Using the following type of login sequence where a site-key or user selected personal pass-phrase to assist in identifying phishing sites is used:

Enter username and simple secret value (e.g. postcode)
If invalid they are provided an error: username or value is incorrect
If these are valid the users personal site-key image is shown and the password is requested
If invalid password, error message incorrect password
If valid access granted

As opposed to the more friendly way on say Quora.com where you get shown your picture on correct username entry. Is this acceptable only on low risk Q&A site?

My colleagues argue for keeping usernames secret and the above type measures:

Mass username enumeration allows you to try dictionary and bruteforce attempts against a site
it enables you to dos a site by locking all the accounts where account lockout is enabled
Users like to use the same username and password across sites and many sites use e-mail address and mobile number for their sites.  If users share credentials between sites, then credentials could be stolen or phished from the other sites and then used to access your site
Publicly known facts, such as mobile and e-mail, do not count towards authentication strength.  If username is a known fact, to maintain the same level of security the password must be significantly stronger to make up for the statistical difference e.g. if username and password both have min of 6 characters, then assuming 52 possible characters we have 52^12 combinations. However, if username is a known fact then that becomes just 52^6 combinations; you have to increase the password to 12 characters minimum to get the same level of protection – failure to do this would increase account takeover risk.

I counter for each:

Your real control against this is password length, complexity and account lockout policy
You can mitigate this by having auto unlock after period of time (e.g. 5 - 30 mins), have a mass unlock function, have exponential back-off or IP banning for a period of time after a number of bad attempts, selective anti-automation controls (e.g. Captcha, Roboo script) displayed after a number of failed attempts
User education, a second authentication factor, adaptive authentication (e.g. step-up or graduated authentication based on device ID, location etc) would be better defenses against this
I see username as identity and password as authentication. If you want a stronger authentication make the password longer or require 2 passwords - leave identification alone

Happy to learn and change my position. Thanks in advance.

Conventional Wisdom re: Brute-Force Attack or Enumeration

There are a few ways to look at this. One should start with http://thedailywtf.com/Articles/The-Phantom-Password.aspx before trying to really think about it, though.

There are varying degrees in which passwords are disclosed. My username at Slashdot is known by everybody who reads a post of mine. My username at work can be viewed by everybody in the office, and equally discerned by anybody who knows my email address. Nobody should know my bank account number (which is the username for my online banking).

In each of those situations, the benefit of specifically saying that the username is invalid or that the password is invalid is limited. Now, in that scenario: If you're on Slashdot, you know the account is there forever so you can figure it out regardless. If you're attacking my work, that can give away whether I'm still employed. Against my bank or credit card accounts, that's the only way to enumerate accounts. It provide a clear goal.

I'm of the opinion that since acknowledging one or the other has limited value for public systems and can leak information about private ones that password authentication should always be of the form "do the username and password match?" That is a T/F question with no steps in between.

New Age Wisdom re: Phishing

A user gets to a website, which may be the wrong website. They enter their login credentials without paying attention to the URL (or perhaps they really get spoofed), and their account is compromised. Banks have addressed this by making authentication a multi-step process. To this idea, the original questioner mentions displaying a series of photos if the username is correct. I counter: ALWAYS make the authentication process go through all the steps. jonjacob(jinkleheimerschmidt) may not be a valid login, but you should still display a series of photos and ask for a password. That allows you to stifle the risk of leaking information and still attempt to prevent phishing from compromising a user account.

Risk v. Reward

The conventional wisdom about usernames and passwords above is simple and agreeable to most, I believe. Phishing is a new variable, and dealing with that is going to change the situation for some systems. There are answers to your question which may not be discussed here, or even thought of yet. I still believe, however, that you should be able to prevent somebody from enumerating accounts with any situation.


Can I safely sell a used keyboard without risk of new owner recovering previous inputs? As far as of my knowledge goes, keyboard don't store keystrokes in their memory by default (excluding those bundled with keyloggers). The thing that comes to my mind though is that some keyboards do have some built-in memory for storing user's preferences (e.g. gaming keyboards). Can this be somehow reprogrammed to store other data than just LEDs color combo?

Can I sell my keyboard without worrying that new owner might recover previous input in some way?

Cheers,
Dominic

Can this be somehow reprogrammed to store other data than just LEDs color combo?

Yes. Anything that have writable memory and a processor can be programmed. Will it be reprogrammed? I seriously doubt.

  Can I sell my keyboard without worrying that new owner might recover previous input in some way?

You can sell it, no worries. You haven't exported the firmware, reverse-engineered it, reprogrammed it and changed it to record everything, so there's no previous input saved anywhere.


Is Drupal's filter_xss enough for filtering HTML? Drupal has filter_xss function. Is it safe to use for filtering arbitrary user HTML input?

If not, what should be used instead when using Drupal 7?

This questuion is a duplicate of Drupal's built-in xss filters vs. HTML purifier module but answer of that seems incorrect to me as filter_xss doesn't contain code for validating HTML

I'm not sure whether Drupal's filter_xss is safe.  According to the link you provided, Drupal's filter_xss is based upon the kses library for HTML filtering.  To put it bluntly, I don't trust kses or kses-derived filters.

If you look at the code of kses, it is based upon a monster regexp.  That's a crummy architecture for a HTML sanitizer, and I don't trust anything that's built in that way.  If you have to filter arbitrary HTML, the proper way to do it is to parse the HTML and then operate on the parse tree.  (HTML Purifier works that way, and partly as a result, I trust HTML Purifier a lot more.)

Historically, kses has had some security problems.  See, e.g., Vulnerabilities in kses-based HTML filters and HTML Sanitisation: The Devil’s In The Details (And The Vulnerabilities).  I don't know whether those vulnerabilities affect Drupal's version, but they don't inspire confidence.  So, if I needed HTML filtering, and if I were choosing based upon security, I think I'd probably choose HTML Purifier over filter_xss.

I should also back up a little bit.  You didn't say much about the situation you are facing.  Are you sure that HTML filtering is the right tool for your job?  In my experience, it's a lot more common that you need HTML escaping (output encoding) rather than HTML filtering.

If you are including untrusted input into a HTML document, you need to decide what kind of functionality you need:

HTML escaping, aka output encoding. Is the user-provided input "just plain text", with no rich formatting?  If yes, use HTML escaping (also known as output encoding), not filter_xss.  When doing HTML escaping, you want to use context-sensitive escaping, to escape the data in the proper way for the parse context where the untrusted data will be inserted.  To learn more, read the following resources:

OWASP's resources on XSS, including the OWASP XSS overview and the OWASP XSS Prevention Cheat Sheet.  The OWASP ESAPI library has output escaping functions for all HTML parse contexts you are likely to run into.
Filter user input before the database or upon display?
Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems

HTML filtering. Do you want to allow the user-provided input to contain rich HTML formatting?  Do you want to allow the user to enter in nearly-arbitrary HTML, which you want to include verbatim into the output document?  If yes, you need a HTML filter.  In this situation, HTML Purifier is an excellent choice, and probably safer than Drupal's filter_xss.  That's just my personal opinion.

When inserting user-provided input into a HTML document, my experience is that probably 95+% of the time you want HTML escaping, not HTML filtering.  HTML filtering is the exception.  (How often do you expect users to enter in HTML markup?  If you're writing an application for the general population, the answer is: almost never.)  So, are you sure you need a HTML filter anyway?


Is it secure to set the encryption password the same as the root password? When installing Manjaro Linux, it shows the following screen:

What's the logic behind that?

I don't have enough reputation to comment, so I'll post as an answer.

In general terms, you should never use the same password twice.
Manjaro is only enforcing and trying to make it mandatory.

Maybe this answer here can give you a better overview.


Where is future of computer security? I know its kind of a "hard to answer" question, but I was thinking, googling and reading about it for a week and I still can't make a decision. So, where do you think the future of computer security is? Web applications? Smartphones, Androids, etc? Computer security focusing on worms/viruses, which are a big threat in the last few years? I am asking, because I am choosing my polarizatoin on university right now. Thanks.

The future or security depends on the domain, there are a few "curves/paths" to consider

Applications will get more complex - more room for bugs and holes
Security is big business and is part of more com sci programs, younger programmers may have more knowledge and inclination to care about security
Complete platforms with apps are becoming more popular - iphone, xbox 360, etc. By limiting the developers and the deployment options, vendors can (but not necessarily) may have more security reviews
At the same time, there are more web apps then desktop apps - you have one website/app with many attack vectors (database, javascript, backend language, SSL)
At the same time, "older techniques" are becoming more difficult and security is being built it - address randomization, sandboxing, DEP, etc.
In addition, new programming paradigms and processes are emerging- there is a greater focus on the process then the end product, so more debugging, helper functions, frameworks which provide methods to automatically filter out injections

Now that is a general picture of where security is going. There is a greater consciousness for security, and constant changes in vecotrs; however, single activities may be very complex, interact with many systems, so there is room for holes anywhere.

It sounds like you are looking for an area to specialize in for your studies. My recommendation would be to get as broad as possible experience - everywhere you can. Unless you are planning on being in QA, as a security person, you need to be well rounded. In a corporate IT security role, you will need to primarily know how to manage the operating system security and security process. Do you know how AD works, how to set up permission? RACF for mainframes? PAM on linux? You may find that you would have a half security half sys admin role. If you are a hardcore programmer, you know C++ and assembly, then you could get a position as a virus researcher or developing algorithms to stop decompilation. These jobs are far fewer, but if you have the qualifications you will have fun looking through code and trying to bend it. If you want to be a pen tester, you really need to know how network traffic works, patch management, how to research exploits given information you discover on the fly (e.g., found this service I have never seen, connect with telnet/netcat and try to get a response or find someone who knows how the service works and try to get it to give me data). You could also be in QA or development or do application and web application pen testing, which requires knowing effective programming and just knowing how to spot things which are wrong.

Ideally, you should get experience everywhere. Unless you find a small niche shop, you will likely be doing a wide array of "security things". You might also end up in Audit, which often in IT is security-focused, but is not quite security. You are unlikely to be a "worm specialist". If you have programming chops, you may be asked one week to look at an iPhone app, the next week a web app. You need to know how to write those types of apps first before you can start to break them.

Likely, your background is either sys admin and IT or its programming. If its programming, learn as many languages as possible, make sure you understand databases as most apps regardless of devices, desktop, or web will write data to databases. If you are a systems or general IT guy, you might not be a "code" guy and instead you can focus on system hardening and network level security (firewalls, SIEM, log management).

Again, the key is to be a quick learner and to experiment in a lot of area. Grow your knowledge over time. You are better off long term being a generalist; you could be a SAP identity management specialist, but if you can't find a company who has SAP or cares about security or if SAP just dwindles in popularity, it will get real tough real quick.


Can I connect to a network without being detected? Some people use software like whoisonmywifi and so on.

Is there a way to bypass this software? I think it pings all IP addresses like 192.168.1.0/24 so it will ping all addresses.

Can I disable the ability to be pinged? Can I bypass this software?

You could sniff the network for traffic and change your network configuration to an active machine(i.e. MAC address):

# ifconfig wlan0 down
# ifconfig wlan0 hw ether DE:AD:66:55:12:34  <== sniffed MAC
# ifconfig wlan0 up

assuming wlan0 is your wireless network interface. On Windows you can do something like this.

Now there should be two work stations with the same network configuration, so it's difficult to tell who is who since whoisonmywifi can't tell the difference. You can always clone the access point(the router itself) so that your traffic becomes more difficult to block(at least to non tech savvy people).
Note that the network may be less stable due to the conflicting packets arriving to both connected machines(yours network session is (most likely) different than the one on the machine you are impersonating).

In order to sniff traffic you can use wireshark and set it to your wireless network interface(i.e. wlan0).


Reissuing certificates with SHA-2 I recently setup my own CA, and imported the CA cert into devices across the company.  I then deployed certificates to our various servers, etc..  All using SHA-1 signatures (the default in the tool I was using: XCA).

Today I discovered the SHA-1 warning in chrome when browsing any of our servers.  Oops.  Can I just issue SHA-2 certs to our servers and chrome will be happy?  Or will any cert in the chain (including the root CA) using SHA-1 cause the warning to appear?

If so, I assume I have to create a new root certificate and distribute that too?

The next question is what's the the best signature algorithm to use?  Should I go right up to SHA-512 to avoid encountering a similar problem in the next year?  or use SHA-256 for compatibility?  (I don't know if some browsers have trouble with the larger hash values).

With regards to Chrome browser:

Self-signed certificate that is inside your trust store is OK with SHA-1.
Root cert is OK with SHA-1. (This is just repeating point 1 in other words.)
All the other certificates in the chain need to be SHA-2. SHA-1 generates a warning.

The cause for the special treatment of self-signed trusted certificates (aka root certificates) is that they are umm... self-signed, therefore what shows in their "signature" field is rather cryptographical kind of nop, than a real security device. Verifying their signature provides next to zero additional security.


Why does Windows 10 have so many open ports by default? Looking at Windows 10's firewall settings, I see dozens of authorized applications, for most of which I can't find a good reason to allow incoming traffic.

For example, I don't want Xbox, Twitter, MSN, Microsoft Edge to receive unknown traffic from the Internet.

I assume that these settings don't include traffic on already established connections (like the ESTABLISHED and RELATED states in Linux's netfilter). Indeed, I disallowed Microsoft Edge in the firewall and I still can browse.

Why does Windows allow so much applications in the firewall by default? Isn't this a security risk (for example, any of these apps could be exploited)? Is it safe to disable them all and block all incoming traffic?

EDIT : to be clear, I am only talking about inbound connections that happen without having been previously established by an outbound request. I'm totally fine with allowing all outbound connections, as these are initiated by my software.

"Authorized Applications" does not equal "Open Ports."   These applications have authorization to communicate through the firewall...This does not mean that they're listening on ports open through the firewall.   In the case of many (if not all) of the application you listed, that means that when you open them and try to use them, they can establish connections to get the data requested.  If you don't open Twitter, it isn't listening.  If you do open Twitter, it still isn't listening on a port for in-bound connections.   The fact that it's an authorized application means that you expect the firewall to allow it to communicate as it is designed to do.  In this case, that's primarily going to be reaching out to the Twitter service to retrieve tweets.

So, while you are correct that you don't want services you don't need listening for inbound connections on open ports, that isn't what's happening here.


Why is the Key Derivation Function important? Let's consider this openssl command :

openssl enc -aes-256-cbc -pass pass:PASSWORD

Why is it important to have a good Key Derivation Function? This answer to another question suggest that GnuPG is preferable to Openssl because Openssl's KDF is weak. As far I my understanding goes, the only thing that is important to get in order to decrypt an encrypted file is the 256-bit key used by AES. Why is the way the password gets transformed into that 256-bit key so important?

"the only thing that is important to get in order to decrypt an encrypted file": I think this is where you go wrong in your reflection, if I can say so.

The only thing which is important is not for you to decrypt your encrypted file, but it is to prevent other to decrypt it by guessing your password.

Therefore, a good key derivation function will make it computationally hard and slow to derive a key from your password so relatively few different key candidates can be tested by an attacker over time. The answer you link mentions that GPG implements this by using a large number of iterations to derive the actual key from the password.

If the key derivation function does not take this precaution, then an attacker will be able to test a very high number of password candidates very quickly (the answer you link states "several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU)", at this speed one can expect to cover all 8 alphanumeric characters strings in easily less than an hour, so the password does not even need to be a guessable dictionary word to be crackable).


Can we use a public key scheme for performing cryptographic commitment Is it possible to use a public key scheme such as DSA as a commitment scheme? Are there any problems with doing this?

The answer can be yes or no depending on what you mean by commitment.

In a commitment scheme, you have a piece of data (d) from which you compute a value c which you publish; at a later date, you publish d. This is a commitment if the following is true:

From c, one cannot recompute d.
Everybody knowing c and d must be able to ascertain that they match.
It must not be possible, even for you, to find a d' distinct from d but which still matches c.

On the surface, this looks a lot like a cryptographic hash function, with some subtle details. If you compute c as h(d) for a hash function h (say SHA-256), then you fulfill the commitment properties, except that the commitment is vulnerable to exhaustive search on the data d. One could try potential data elements d, and hash them all, to see if one matches c. That's a problem also encountered with storing password hashes. The solution is randomization: you compute c as h(r||d) where r is some random padding (say 16 random bytes). When you open the commitment, you publish both r and d. The randomness of r protects against exhaustive search.

What would a signature scheme like DSA do in that picture? Not much, really. Instead of hashing, you could sign, but since everybody can verify the signature, you still would have the exhaustive search issue (DSA includes some random data, but not in the "right place" for a commitment scheme). Indeed, DSA begins by hashing the data, so you are really using a hash function, and the DSA around it is a needless complication.

Some commitment schemes provide more than just the ability to commit to an arbitrary value; they also allow to prove without opening the commitment that the committed-to value fulfills some algebraic properties. This is used, for instance, in some electronic voting protocols (the vote is encrypted, but the voter can show that the vote is either a 0 or a 1, not another integer). This kind of commitment requires mathematics besides just a hash: it may reuse some elements which are also used in some asymmetric encryption and signature algorithms (like operations modulo a big prime), but not just the asymmetric encryption or signature algorithms alone.


What type of information should be shown to an end user for a logon session summary? Google, Yahoo, Facebook and several banks have a session summary screen that lists a variety of information, but they aren't consistent in what is offered to the end user. e.g.

Facebook offers a concise "active session" list, and enough information to determine if that session should be terminated.
Chase bank,  for example, lists how many transactions have been issued in the current session, while there is a larger (and overwhelming) set of options in Google.

Excluding the line of business details (as in the Banking app), what session information and controls (eg terminate session) should be included on a session summary?

Edit: The thought is that providing too much information in a session summary could be used by a malicious person or script accessing that page.  e.g. an account could be hijacked, the password changed and all legitimate sessions terminated.

Other social engineering, or PII disclosure may also be possible depending on the type of attack.

If the link is not secure, nothing at all should be shown.

The rest of the post assumes a secure link.  The following is relevant:

if other concurrent logins exist, or failed login attempts, very important, show as much details as possible so that the person can identify himself;
last monetary on-line transaction;
last monetary off-line transaction;
details of current login and timeout;
fraud numbers and links;
verification that the site is authentic or a method to confirm.

Basic information about security related matters in a link.

I think PayPal is a good start.


Exploitability of allowed wildcard (*) CORS Origins with Bearer Token Authorization I'm looking at the following setup. A web application uses a REST API to communicate with the server. All API responses include Origin: *. For authorization Authorization: Bearer <token> is used. Access-Control-Allow-Headers: Authorization is also included for appropriate preflight requests.

As Origin: * is configured, modern browsers will not send authorization data, such as the bearer token.

This makes it impossible to use API requests across domains, which require authorization.

I'm struggling to justify, why this should be considered a vulnerability. It is bad practice to allow any origin. It could lead to data leakage, but not in this scenario.

Could this be exploited in another way, I'm not seeing right now, or is this in fact just bad practice and does not pose an actual threat?

EDIT: The CORS response headers are (Origin: * is a request header):

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization

ACAO: * will prevent the browser from automatically sending any form of credentials, but that's only relevant for the kinds that the browser can actually send automatically (cookies and HTTP BASIC, DIGEST, and NTLM auth). HTTP auth does use the Authorization header, but not with a Bearer token. Because ACAH: Authorization is specified for both the pre-flight and the actual request, the caller is completely free to explicitly attach an Authorization header (with any value at all, including a Bearer token). The difference is that the caller needs to actually know the value to put in that header; it won't be automatically added by the browser.

Given that the attacker would already need to know the bearer token and that the browser isn't automatically including any secrets with the request, there is no security vulnerability here at all. Allowing the browser to make such authorized requests from arbitrary origins is fine; it's exactly equivalent to the browser making a same-origin callback to its own server, and having the server send the request (which would ignore CORS because most HTTP client libraries don't even have a concept of the same-origin policy) and relay the response back to the browser. In other words, this is no greater security risk than any other web service protected with a Bearer token.

Of course, this is all assuming that the web service is supposed to be reachable from arbitrary addresses. If it's not - if for example it's only supposed to be reachable by one company - then it would make a little sense to restrict the allowed origins more tightly. Only a little, though, because anybody with an HTTP client library (and the bearer token, without which the attacker cannot do anything if the auth is otherwise solid) can make requests all day, unless there's also something like an IP whitelist.

The primary and critical part of the security of the service, as you've described it, is the bearer token. To a first approximation, nothing else matters.

With that said, there are of course many other potential vulnerabilities to check for. Obviously, you should verify that the Bearer tokens are at least as secret as the information they authorize access to; it's no good to require authorization to access a web service and then push the required authorization data to a Git repo, for example. Similarly, make sure the valid Bearer tokens cannot be guessed, brute-forced, or found via timing attack. There are lots of ways to screw up auth, and even more to screw up web services in general (is it available over HTTP, or via weak HTTPS cipher suites? Does it have deserialization or XML DTD vulns? Standard web security stuff).


How can I check if my second hand Apple wireless keyboard contains a keylogger? I just got a cheap second-hand magic keyboard (Apple). Is there any way to check if it's been key logged? I cannot see any screws or openings other than the one for the battery pack.

This would be practically impossible. Off course, you could open it up and see if there's any strange looking components who doesn't seem to belong there. But how would one tell what's legitimate and what's not? Plus, the keylogger could be in the firmware, meaning it's not hardware and can't be seen directly.

That it's a Bluetooth keyboard makes the situation a bit special. An ordinary hardware keylogger would probably be attached to the cable going from the circuit board out of the keyboard. That makes it a bit easier to detect. But you can't install something like that on a wireless keyborad since there is no cable. That makes it much harder to install a keylogger, but also much harder to detect one if it's installed.

But in the end, the likelihood that your second hand keyboard would contain malware is small. Unless you have some specific reason to believe you may be under a serious targeted attack, you probably shouldn't worry to much about it. Chanses are there are bigger risks elsewhere to care about first.

But if the risk do bother you, your best bet is to by a new keyboard rather than examining the second hand one.

TL;DR: You can't really check if it's been keylogged, but in practice you don't really need to anyway.


How do you stop a hacker with no IP and a dot for their HOST The entry below is from the visitors log in c-panel

Host: .
/specific legimate-wordpress-post/
Http Code: 503
Date: Jul 24 09:28:06
Http Version: HTTP/1.1
Size in Bytes: 1118
Referer: http://mywebsite.com/
Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10

/?_wfsf=unlockEmail
Http Code: 200  Date: Jul 24 09:28:06   Http Version: HTTP/1.1  Size in Bytes: 242
Referer: http://mywebsite.com/specific-legimate-wordpress-post/
Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.1

The entry below is from the raw access log in c-panel

. - - [24/Jul/2014:09:28:06 -0500]
"GET /specific-legitimate-wordpress-post/
HTTP/1.1" 503 1118 "http://mywebsite.com/" "Mozilla/5.0 Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10"

. - - [24/Jul/2014:09:28:06 -0500]
"GET /?_wfsf=unlockEmail
HTTP/1.1" 200 242 "http://mywebsite.com/specific-legitimate-wordpress-post/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10"

This site is on a shared server so there is no access to server configuration files. Would you use hosts.deny and .htaccess to stop such a hacker and if so please explain how in detail. Thanks.

You start by figuring out what's going wrong with your logging.  Everyone on the Internet has an IP address -- it's a necessary condition for connecting to any other computer out there.


Why after dd'ing ISO file to entire USB flash device, only the first partition match the ISO checksum? I use dd to "burn" an ISO file to USB stick:

dd bs=4M if=/mnt/media/ISO/Fedora-Workstation-Live-x86_64-31-1.9.iso   of=/dev/sdd conv=fdatasync  status=progress

Now I can see several partitions has been created:

sdd      8:48   1   1.9G  0 disk
├─sdd1   8:49   1   1.8G  0 part /run/media/alex/Fedora-WS-Live-31-1-9
├─sdd2   8:50   1  10.6M  0 part
└─sdd3   8:51   1  22.2M  0 part

Why only sdd1 matches the ISO checksum, not an entire drive? I checked files on other partitions, they contain this ISO related files..

It's not clear to me what you are trying to accomplish.

You appear to be writing a file to a raw device. Unless the file is a disk image appropriate for that kind of device, this makes no sense to me.

The Fedora-Live ISO is a SquashFS file system, not a binary or raw image suitable for dumping to a raw device.

Since this is a Fedora-Live ISO, I'm guessing that you want to create a bootable USB vice the bootable DvD you'd get from simply burning the ISO to a DVD. There are standard tools for doing that such as: Unetbootin

          ****** edit *****

OK, I pulled down the ISO file and did an fdisk of the ISO.

  fdisk Fedora-Workstation-Live-x86_64-31-1.9.iso

  Command (m for help): p

  Disk  Fedora-Workstation-Live-x86_64-31-1.9.iso: 1.8 GiB, 1929379840
  bytes, 3768320 sectors Units: sectors of 1 * 512 = 512 bytes  Sector
  size  (logical/physical): 512 bytes / 512 bytes  I/O size
  (minimum/optimal): 512 bytes / 512 bytes  Disklabel type: dos  Disk
  identifier: 0x6f869649

  Device                                     Boot Start     End Sectors
  Size Id Type

  Fedora-Workstation-Live-x86_64-31-1.9.iso1 *        0 3768319 3768320
  1.8G  0 Empty

  Fedora-Workstation-Live-x86_64-31-1.9.iso2        172   21887   21716
  10.6M ef EFI (FAT-12/16/32)

  Fedora-Workstation-Live-x86_64-31-1.9.iso3      888   67407   45520
  22.2M  0 Empty

The ISO defines 3 partitions of which 1 & 3 are Type 0 Empty.


Reconnaissance countermeasures I have a lot of XMAS/NULL/SYN packets (+-1000 packets/day/server) from same IPs (+-120 differents IPs from anywhere) on multiple servers. Logs and firewalls are checked daily and servers are updated.

Do I have something to do with those ips (e.g. nslookup, whois, complain to ip owners) ?

Something else to do ?

Thanks in advance

This is typical low-level scanning, it's not uncommon for servers to see hundreds or thousands of scanning attempts per day.

You are not required to notify anyone, in fact the majority of people and companies out there take no action, they just accept being scanned as part of connecting to the internet.

You could notify the email address listed as maintainer in the whois entry for the IP block that you are receiving scan traffic, who knows, they may even fix it. I wouldn't hold my breath though.


Is breaking a looping one-time pad practical? If so, how? A one-time pad is known to be theoritcally secure, nothing can break it. However, if the key is reused, the one time pad becomes theoritically breakable.

But even RSA is theorically breakable yet it's widely used because it's practically secure. So, is a One-Time pad with a sufficiently long looping key practically secure?

If it's secure, how long does the key need to be in order for it to become practically unbreakable on a modern PC?

If it's insecure, why? how does one break it?

An example of a looping OTP Key:

LemonLemonLemonLemon........

The one-time pad is trivially breakable if the key is reused in any way.

C1 xor C2 results in P1 xor P2 where C1 and C2 are the two pieces of  ciphertext encrypted with the same key and P1 and P2 are the corresponding plaintext.

You can then recover the plaintext with the following method. You take a common word or phrase that may appear in the plaintext (such as " the ") and xor that against the result of P1 xor P2. If one of the plaintexts had the text of the crib (" the " in our example), then the result of the xor is what the other plaintext had in that position. If neither plaintext contains the text of the crib, it is very likely that the result of the xor is just gibberish.

You simply continue this technique until you recover enough of the plaintext to guess the rest from the context. This attack is known as crib dragging.


How to protect my computer from being tracked by a web site? Many sites track/trace users when the visit it. What I mean by that, is  let's say I visit a page then the owner of the site sees that one person visited his site.

Is there any way to be protected from that? For example, when I get on a site the owner can't see that I visited it?

can't see that I visited it

You can prevent an owner knowing the you personally visited. To do so, you need to mask your originating location. Either via something like TOR or via a VPN than changes you address on each request. You also need to mask your browser signature since that may also be used to track you. Using Incognito/InPrivate sessions, refusing cookies and other local storage and changing parameters such as local IP address, screen size, etc. - or alternatively keeping them static but at the most common possible values so that you cannot be detected from everyone else.

You cannot, of course, prevent them from knowing that someone visited.


How can I map CVEs to their underlying CWE? I was tasked with developing a consistent, relatively complete map for CVEs to CWEs at my internship, and I'm kind of at a loss finding a method to find a 1-to-1 way to map CVEs onto CWEs. Ideally, this would all be automated in the end. The format isn't important, a spreadsheet, text file, database etc are all fine.

CWE and CVE are very different things, which can't really be mapped arbitrarily from one to the other. CWE is a categorization system for vulnerability types, while CVE is a reference to a specific vulnerability.

But a specific vulnerability can be references by a CVE and also be categorized via CWE (something the researcher who discovered the issue or the CNA who assigned the CVE may have done).

You could scape nvd.nist.gov or cvedetails.com, both of which have a CWE entry for CVEs (see https://nvd.nist.gov/vuln/detail/CVE-2019-10086 or https://www.cvedetails.com/cve/CVE-2019-10086/ for examples). You could also look for CVE APIs which contain the field (this related question has one example).

But for many CVEs - especially older ones - a vulnerability might not be categorized via CWE. You could try to map the Vulnerability Type field from cvedetails.com to a CWE, but if that is also not set, you'd need to categorize the vulnerability manually.


In two step authentication, should I check step 1 before proceeding to step 2 or check both at the end? I asked this question first on Stack Overflow but it was suggested that Information Security would be a better place for it (pretty obvious in hindsight).

https://stackoverflow.com/questions/24304756/in-two-step-authentication-should-i-check-step-1-before-proceeding-to-step-2-or

I have a typical web application forms authentication process with two steps:

Step 1: Request username and password
Step 2: Request some characters (for example, 2nd, 5th and 8th) from a secret phrase

Should I authenticate the username and password before going to Step 2? Or should I collect all three bits of information (username, password and characters) and check them at the end?

Most websites I've seen check the username and password and if they don't authenticate, never ask for the characters. On the other hand, it could be argued that checking everything at the end and if they don't match, displaying an error message that doesn't explain which bit failed would be more secure. That gives away less information like displaying "Username or password is incorrect" (without specifying which) in a simple 1 step authentication.

The problem with the second approach (aside from being less user-friendly) is that Step 2 requires obtaining a valid user in Step 1, otherwise it's hard to know the length of the secret phrase to ask for valid characters (there's no point asking for the 10th character if the phrase is only 9 characters long). The application would also have to hold on to the password in a secure manner between the two steps.

So which one is better? Is there a third approach I should consider?

Don't do this!  This is stupid.  If it is a client requirement, push back on the client.  You are supposed to be the expert.  Tell the client when they are doing something that doesn't serve their interests.  This is simply an elaborate single factor authentication and provides absolutely zero additional security over a slightly longer password requirement.

The client may think that this is a second factor, but it is not.  For two factor authentication it must be two DIFFERENT factors from something you have, something you know and something you are.  These are both something you know, so no additional security is provided beyond the extra characters on the password, it is just a little more convenient that having to type the entire phrase (which is basically a long but very weakly chosen password).  It also has no impact on preventing hash attacks against the stored password (and online brute force shouldn't be possible due to account lock outs.)

If the client still wants this despite the lack of any actual security benefit, I don't see any way not to do it as two steps since, as you point out, you don't know how many characters to choose from unless you know the length of the phrase that it is going to be working off of and hopefully at least the secret phrase is protected by their password (though I somehow doubt it).


What makes this cellphone (and the weird instructions) so privacy-friendly? I stumbled upon this weird product in a webstore primarily selling Cannabis-related products (not the actual herbs): https://smoketower.com/nyheter/Anonym-3310-mobiltelefon
I've manually translated the Swedish product description for you into English:

Small cellphone for the more sensitive calls. Keep anonymous by setting up the telephone to completely hide your number from the person you are trying to call. The phone has a 2 Mp camera and a socket for 2 SIM cards plus 1 micro-SD for extra storage. Micro-USB cable included for charging.
To ensure your anonymity, you must follow these instructions:

Press the Menu button
Go to Settings
Choose Call Settings
Choose Hide ID
Choose the first option 'Hide ID'

The price (449 SEK) is about $54 USD.
What exactly makes this "3310" (is that supposed to refer to an old Nokia model from the late 1990s or early 2000s?) such a privacy-friendly phone? And what's with the instructions to set some setting inside the phone?
I know for a fact that this is a real store with lots of customers, so it can't very well be a complete scam. I just wonder what they mean by this and how this could possibly make anyone anonymous, especially as the SIM cards cannot be bought anonymously since many years now, and that phone will just leak the physical location whenever powered on anyway?
Is that "Hide ID" setting unique for this particular phone? Is it a standard feature? What does it mean? Why can you "hide your ID" in some setting? I'm very confused about this.

Nothing. The phone simply has an option to not your send caller ID (i.e. your phone number) to the person you are calling. Nothing too special about it. In fact a lot of telephone network providers already provide a way to do this, so you don't need a special phone for it. Note that this will not prevent law enforcement from tracing your calls if they want to. All it does is not send your number to the person you are calling.


Ransomware - All computers infected but one Let's say there is a particular network which has a "monthly" successful cryptolocker attack. Every time, every computer in that network is infected.

The set up is like this:

1x Windows 2003 server (SMB1)
4x Windows 10 Client computers

Every time, the server and 3x Windows 10 machines are infected. 1 machine remains unaffected.

They are all part of the same domain.

Is it possible, that a virus infection resides on that one computer that never gets infected, and spreads the crypto onto the other machines without infecting it's host? Has anyone experiences likewise behavior?

The concept you are looking for is "persistence". You don't want to destroy your route to continue to extort the victim.
If you encrypt the machine that is your route in, then the victim will reformat/reinstall the operating system and wipe out your route in.
So, you leave the one machine (likely the first infected machine) alone, but launch attacks from it to the rest of the network.