PBKDF2 strong salt for client-side hashing

First, make sure you read this answer to the question "Client side password hashing", paying particular attention to the last paragraph.

Also, please realize that client side javascript is going to be incredibly slow at PBKDF2 compared to good server side code.  At least try to find a PBKDF2 implementation that uses HMAC-SHA-512 as a base.

That said, if you want to give the user peace of mind, that's fine; do the following:

Client side PBKDF2 hashing for a known, "high" iteration count.

Double bonus points if the user is allowed to select the iteration count themselves!
I put high in quotes because I doubt your javascript code's going to be fast enough to do tens or hundreds of thousands of iterations in the time you can get enough of your user base to accept, particularly on cheaper mobile devices.
A good hash of the username and password as a salt isn't great, though it's better if your code pads the username out to the maximum possible length and puts it first.

That way, "user1" and "password" don't make the same salt as "user" and "1password"!
There is, of course, no maximum length on the password except what's caused by your back end software; SQL Server, for instance, has an 8000 byte maximum on "less inefficient" string work.

Send that hash by itself to the server

which then DOES generate a cryptographically random salt of 12-16 bytes
and then uses PBKDF2 with a much higher iteration count to hash the hash passed in

again hopefully HMAC-SHA-512 for the 64 bit operations to lessen the proportionate advantage of offline GPU attacks.
because then someone who gets your leaked password database still has to do the work of an attack against a password hashing function to log in, rather than simply sending the client-generated hash they stole and having it be accepted as-is.

Remember with PBKDF2 password hashing in particular, never ask for an output size larger than the native base hash's output size.  Smaller is all right if you're really, really concerned about storage; for instance, requesting only 32 bytes of  PBKDF2-HMAC-SHA-512's native 64 byte output.

20 bytes for SHA-1
32 bytes for SHA-256
64 bytes for SHA-512


How can SSL vendors limit the amount of servers they can be installed on?

There are no technical reasons for such a limit, it's purely licensing (i.e. revenue, and maintaining market segmentation). There are some considerations relating to the secure transfer of the key between systems when you do this, but this is easily addressed.

If you violate the license or terms of an agreement you risk (at least) getting your certificate revoked.

They (the CA/reseller) might be able to tell how many servers you have by:

inspecting your site for signs of load-balancing (e.g. different server signatures or E-Tag headers), or even just multiple DNS A records
monitoring OCSP stapling requests and recording the source IPs and frequency of requests, in the unlikely event you have this configured

Neither method is reliable and conclusive however.

It is possible to put public IP addresses in certificates, though some CAs do not support this (e.g. GoDaddy). This is not commonly used in for standard "web" certificates. Such a "name" is only checked by browsers if the URL contains an IP address in the host part (i.e. the browser doesn't check both IP and DNS for URLs containing DNS names). Web servers don't tend to check the certificates they are presenting as thoroughly as a browser, and assume the administrator knows what they are doing. Even if this worked as a method of limiting concurrent use by causing (user-visible) browser errors, it would only be effective if all servers had public IP addresses (no NAT or front-end proxy/load-balancer).


Is a handwritten scanned signature equivalent to its paper counterpart?

Authentication, Integrity (?) and non-repudiation are digital infosec terms, and what you want are the electronic terms.

Are you in the United States?  The American Bar Association has extensive guidance on this.  Try Digital Signature Guidelines: Legal Infrastructure for
Certification Authorities and Secure Electronic Commerce for some basic information (the front talks about scanned wet signatures, but the rest of the document is a 'must read' for the use of digital signatures, which is related but off topic.)


Integrating ZAP to SDLC. Am I doing it right?

Is it working for you? If so then yes, you are probably doing it right ;) ZAP is a very flexible tool and many people use it in different ways. One question - are you restarting the ZAP instance, eg for each scan or after a period of time? If not you may run into issues as ZAP is not really designed to be run as a long running process. We are working to change that, but we're not there yet.


Is Android ( Linux ) emulating a read-only USB storage device safer than a USB drive?

I will say that read-only/write-protected USB drives do exist.

One solution (the only I'm aware of) is from KanGuru, which offers a wide variety of USB drives which have a write protection switch. As far as I'm aware of, it uses hardware to block writes. https://www.kanguru.com/

Linux allows for mounting as a read-only drive, but that is an OS specific solution (but does work quite nicely).

Windows can mount NTFS partitions as read-only, but this isn't exactly "plug and play" as USB drive are. https://superuser.com/questions/213005/how-to-mount-an-ntfs-partition-read-only-in-windows#213015

Using Secure Digital (SD) cards is not a solution, as write protection can be ignored by software as it's just a signal, without any implementation in hardware to ignore write requests.


Secure distributed storing and querying of [medical] data?

Sticking with MongoDB, and will setup:

256-bit encryption of database filesystem (GridFS)
TLS between database servers and applications servers
TLS between application servers and consumers
User authentication on the application servers (scrypt for password, expiring tokens for login, x509 certs required for generating+using client_id, client_secret)
User authentication on the database servers
Internal message-passing queue

Two-time use username+password should be generated and stored in encrypted database.
Password used to encrypt message payload, username added into header.
Popping message hits database for password, which is then used to decrypt payload.

Frontends consuming my RESTful API can add another level of security: encrypting data before it hits my application and database servers. HIPAA and other compliance will also be checked before opening for beta testing.


Password hashes with large internal state

I think you've described SHA-3, where the capacity c (and to a lesser extent, the rate r) are exactly the "very large (tuneable of course) internal state" you're talking about.

You don't have to crank it up very high (512 bits / 1024 bits) to get your 256 / 512 bit security levels.

Remember though that the goal of cryptography is not to make the attacker do a lot of work, it's to make the attacker do a lot more work than than the legitimate user. Hashing involves doing expensive operations on the internal state, so just blindly cranking up the size of the internal state hurts the legitimate user just as much as it hurts the attacker.

Large memory requirements of scrypt is meant to exploit a resource that's abundant to the legitimate user (a server handling a small number of login requests at a time), but scarce to the attacker running on massively parallelized hardware rigs.


Read Write Execute on infected thumb drives

You should also be aware that if the thumb drive is malicious (as opposed to having malware on it) then you should be aware of non-malware attacks that impersonate different types of USB device. It could pretend to be a keyboard and type commands onto your system for example.

If you can reliably prevent execution of any files hosted on the drive, then that would be a reasonably effective solution. Execution prevention of untrusted locations (e.g. Downloads, AppData, etc) is by no means 100%, but it's actually quite effective at tripping up various automated exploits and mass-market attacks.


I am being DDoSed for no reason, how can I protect myself?

Not sure exactly what Arbor Networks provide in terms of DDos their homepage talks about "on-premise solutions". That seldom helps against large DDoS attacks - once the traffic reach your premise, it is already game over.

So what to do? Get behind a CDN that offers DDoS protection, and make sure to change your IP so only your CDN and nobody else knows it. Since only the traffic your CDN lets through will ever reach your server, the attacker must take down the CDN edge node to take you down, and that is an insurmontable task.

Not saying they are better than any other CDN, but this is what CloudFlare has to say on the subject:

  Layer 3 and 4 attacks are difficult—if not impossible—to mitigate with an on-premise solution. If an attacker can send more traffic than a network link can handle, no amount of additional hardware resources will help to mitigate such an attack. For example, if you have a router with a 10Gbps port and an attacker sends you 11Gbps of attack traffic, no amount of intelligent software or hardware will allow you to stop the attack if the network link is completely saturated.

  With CloudFlare, all attack traffic that would otherwise directly hit your server infrastructure is automatically routed to CloudFlare’s global Anycast network of datacenters. Once attack traffic is shifted, we are able to leverage the significant global capacity of our network, as well as racks-upon-racks of server infrastructure, to absorb the floods of attack traffic at our network edge. This means that CloudFlare is able to prevent even a single packet of attack traffic from a traditional layer 3/4 attack from ever reaching a site protected by CloudFlare.


You've just about answered your question.

Can there be a secure way to allow users to "automagically" change their passwords for different services?  Yes...

A standard open API to allow a user to change a web site password is possible and I say it's a decent idea.

Then again, a standard open API to allow a user to log in to a web site is possible and I say it's a good idea.  But, amazingly, web site login process is becoming less, not more standardized; this basic function of a password manager is getting harder, not easier.

Security Considerations:
Well, it makes it easier for a malicious user to cause a whole lot of trouble by changing many of a user's passwords at once.  Resetting passwords will be as time consuming as ever.  However, it's rare that malicious users change a great many of one user's passwords, even when they have the ability.

The password changer could have its own security flaws too, for example it could choose insufficiently random passwords, and implementations of the API could have security flaws.

On the other hand, it's relatively common for passwords to be compromised in ways that would be ameliorated by more frequent password changes.

So I'd say (with low certainly) that the downside is probably not greater than the upside.

I think a better idea would be to standardize and evangelize a free and open API based on the SRP (Secure Remote Password) protocol, or something like it. With SRP an eavesdropper or man in the middle cannot make many brute force guesses, so strong security can be obtained using relatively short/simple passwords. Furthermore the server does not store password-equivalent data. This means that an attacker who steals the server data cannot masquerade as the client.  And if I'm not mistaken, it means that there is less of a problem when users use the same password with multiple web sites.

UPDATE: In the meantime, there's the LastPass Auto-Password Changing feature.


Can one trust OS and apps from Onyx: app store, modified Android, Onyx Cloud

I think this is a personal question, and I doubt anyone can give you a definitive answer. Only you can decide whether you trust a company which offers a certain service, and this in turn depends on the service itself and on your personal threat model.
Are there opportunities here for something nasty to happen to your information? Certainly, but that can be said for every product out there. The real question is: are these risks that you are willing to take in order to use this product? This is the real question.
Also, the question in its current form is probably too wide: all 4 points you raised would require an in-depth security discussion, as the attack surface varies wildly between them. Your attitude to risk could also easily be different depending on the point you raised: for example, you might trust their cloud enough to store your documents there, but you might not want to give them access to other clouds such as Dropbox or Evernote. Once again, this is not something that we can answer for you.
If you are interested in a thorough review, your best best is to reach out to the producer and request some security documentation, so you can make an informed security decision.


As it has been mentioned in the comments, your first example is actually covered by hashcat (hash type 4700). However, it is not possible to create your own, custom hash type "on the fly".


Are SSL certs auto-revoked if their Not-Valid-After date is reached without renewing?

No. Revocation is an active event, not something that passively or automatically happens. Expiration is passive, though. An expired cert is no longer valid, so there's no need to stick it in a CRL or update OCSP.
If the purpose of your checker is only to parse OCSP, then no, you don't need to check the dates on the cert, because that's not part of OCSP. If the purpose of your checker is to answer the question "is this cert valid?", then you absolutely need to check the validity dates (both start and end).
EDIT: As eckes points out, for your typical client-identification or server-identification cert (or any other kind not used for long-term signatures), once it's expired you can actually take it off revocation lists, which helps keep their size down.


How can I create my own public certificate using openssl?

Here's nice walkthrough of all the steps you need to do in order to generate self-signed ceritficate.

http://www.akadia.com/services/ssh_test_certificate.html

You are using wrong parameters. When you are generating new certificate, you've got two inputs - request and private key and one output - the signed certificate.
The correct command therefore would be:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
where

x509 req : you are requesting PKI functionality
days 365 : validitity period for the certificate
in : certificate signing request
signkey : private key used to sign the certificate
out : output file for the generated certificate

Hope this helps.


Using the Synchronizer Token pattern, should you ensure the CSRF token is only communicated via HTTPS?

If an attacker can sniff the CSRF token, then he can also sniff the session cookie and there would be no reason for him to launch a CSRF attack. Or am I missing something?


Will gmail close my well intentioned botnet account?

Using email as a configuration distribution service is terrible. Using an external and uncontrolled server is even worse. As people already stated, you could trip the spam filters and get messages silently dropped, anybody could send emails to the account, the latency between a message being sent and received can be very high (and unpredictable), and other complications.

If your clients have internet connection, you could set up a free server running PHP/Python/Ruby/Node and create a webservice with authentication in place. The clients would connect to it, and send statistics or receive configuration changes.


EMET disable DEP on IE for specific site

No. DEP is enforced process-wide, and you can't switch it off for just one site.

There are two ways around this:

Turn off DEP enforcement in the EMET policy for iexplore.exe
Manually patch the DEP flag into whatever VMware component is being loaded, using a tool such as CFF Explorer (Optional Header -> DllCharacteristics -> Image is NX compatible) so that it is marked as DEP enabled and works alongside EMET.

You should file a bug with VMware about this, as they shouldn't be producing non-NX binaries.


Based on the location of the server in relation to the location of the client, there is a high probability it is indeed a malicious attack of some unknown type. Perhaps not MITM, but something which does illicitly interrupt the connection. The attack could be considered sophisticated because it occurs randomly on an active TLS connection. (Random to the user, on command to the attacker).

Neither the server nor the client are within the possession of the attacker, and the attacker is yet able to interrupt an active international TLS connection at will. Serious stuff. If it is verified to be an attack, state sponsored actors are likely the culprit.

This type of attack is documented in CVE-2014-3466 for GNUTLS as a memory corruption attack, termed the 'Hello Vulnerability'. A bug report or security report should be submitted to bugs AT gnutls.org so that this issue can be studied.

Further information on this vulnerability can be found here:

http://radare.today/posts/technical-analysis-of-the-gnutls-hello-vulnerability/

-and-

http://gnutls.org/security.html


With a properly setup VPN all DNS traffic will be done through the VPN and cannot be intercepted. So you might check the configuration of your unknown VPN solution you use. Apart from that - how did you determine that your ISP is doing what you claim?


When using AES and CBC, is it necessary to keep the IV secret?

From Wikipedia:

  An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

You don't need to keep the IV secret, but it must be random and unique.


CloudFlare - prompted for "attention required"

Cloudflare has stored cookies from your macbook, you may have used proxy or violated something earlier and cloudflare stored your cookies, and the cookie is same every time you visit. So everytime you visit webs behind cloudflare it says attention. Try deleting browser and system cookies and try that website again.


What output can a program, when executed from a command line, output to generate behavior that is a vulnerability on the terminal emulator?

I do not think that a software can send a Ctrl-Alt-Del to the system so easily, this event must come from a physical keyboard. However, what is sure is that with not-so-recent graphical terminal, such flow could be exploited to inject malicious commands.

The clue is that some terminal provide :
 - An escape sequence to update the window title,
 - Another escape sequence to report the window title back to the command line.

When a user uses a terminal sensible to this exploit (most well-known terminal have been corrected during the last few years), it is therefore possible to inject a command on the user's prompt using, for instance, a specially crafted file name (when doing a directory listing) or binary file (when using "cat").

The user would then still need to press "Enter" to execute the malicious commands, but usually there are other escape sequences allowing to trick the user (for instance empty the prompt string, change the command's foreground color to set it the same as the background, so the command itself is not visible, then display something like "Press enter to continue...").


You could try to use Sysinternal's Portmon to see which process(es) broadcasts on 255.255.255.255. Don't be too alarmed before you see what kind of things are broadcasted.

To see a more precise view of the packets sent/received, use : wireshark.


Should we store accesstoken in our database for oauth2?

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though.

For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your users. Of course, simply storing the token in session storage might put it on disk too, depending on your session configuration. Its a good idea to keep it encrypted while you're not using it.

Your proposed scenario about the user clearing cookies and coming back is also an issue. You could take the access token from the database and stick it back into their cookies, but before you do that, you have to make sure they are who they say they are - and now you have to do another layer of passwords just to give them access to the token they already gave you.

You're probably better off simply re-doing the authorization flow when they come back and click the login button again. Its not that expensive. But if that truly is a showstopper for you, then storing the token is an option. You'll just have to be really careful about working through all the associated issues.


Apple Mac Security - What do I need to know?

I think this webpage is a very good start:

Mac OS X Security Configuration Guides

You can download on it several Configuration Guides and Security Configuration Guide for Mac OS X 10.3 (Panther) to 10.6 (Snow Leopard) (but unfortunately right now, not for the latest version 1.7 (Lion)).


Can rootkits hide their internet usage from resource-manager and third party software in windows 10? If so, how?

The resource manager or third party monitoring tools are software running on the computer. They could have vulnerabilities which a knowledgeable attacker could exploit with a malware in order to manipulate their output.

Besides malware acting on the computer it is possible that an attacker modified the source code of the monitoring tool or replaced its executable file in the repository and you installed already modified malicious software that will not report certain network activity.

So, it is impossible to guarantee that the numbers reported by resource manager or a monitoring tool are correct.

It is very likely that they are correct, providing that:

Your system is up to date,
You have an anti-virus software running,
You installed the monitoring tool from a trusted source (and verified its digital signature or a checksum posted on its Web site)

  Is there anyway I can be sure that when there is no upload showing in
  my DU meter and resource manager then it means that there is actually
  no upload happening?

Monitoring network activity by another device outside of your computer (a router, a proxy server, etc) could give you better assurance that the monitoring information is correct.


Does compression level influence security of encryted 7z files?

Compression would affect the encryption if the attacker controls some plaintext of the encrypted data as mentioned in this post.
It may not have an influence for your use case, since the data is archived and not accessed by many people, but if it is sensitive data then spare the extra GB for more security.


Firefox and Chrome use the NSS library which supports generation of SSL key logfiles. This file van be specified by the SSLKEYLOGFILE envvar.

Configure the SSL key log file at Preferences -> Protocols -> SSL and you can capture and decrypt on the fly.


Verifying cryptographically signed files when the key has been revoked

Is there way to tell the differences between a revocation because of
  cycling and a revocation because of compromise?

Certificates.
Certificates usually include validility times, during which the associated public key is valid for use. Most certificates are issued for 1 up to 3 years and afterwards you need to cycle the certificate (and also maybe the associated key). With most better TOFU and pinning schemes you will still see and check the certificate and not solely trust on the pinned key, to ensure that the key is actually still valid and not expired nor revoked (which is handled via OCSP and CRLs).

  But if the verification step only happens some time later, and in the
  mean time I revoke my key, how should this be handled?

This is actually a tricky problem, that requires some (2) changes to the way documents and data is signed and verified.

First, we need to change the OCSP responders. Right now, you usually only get "good", "unknown", "revoked" or "suspended" from the CA as an answer. This is clearly not enough, as you need to know when the certificate was revoked or suspended. Given this information you can actually check if the signature was issued before the key was compromised. Of course this still leaves the issue that anybody could just use a pre-revokation date for signing data.

To fix this issue, you need some more reliable way of time-stamping data than by letting the time stamp be created by the signer. You need to outsoure the timestamp, by either letting a trusted service sign a combination of the hash and the current time, by cleverly chaining the hashes like is done with Certificate Transparency or by insert an entry into the block chain.

As soon as you have a (valid-looking) signature with a trusted time stamp before the revokation date, you can rest assured that the signature is valid, but note that your signature should be included by the hash sent to the time stamping service to ensure nobody ripped it off and replaced it.

The alternative possible solution is to get rid off this whole revokation system and just (exclusively) use short-lived certificates where you can be sure that if it was revoked, that all the data in this short time frame could have been signed maliciously.


Spoofing IP address as being local over the Internet

Yes you can put an RFC1918 IP address as your IP source address.
You can even use a valid IP address within the targeted network you send your packet to.

Correctly configured router of Internet connection should block such a packet coming from the outside with an IP address from the inside. This is what is called Ingress filtering.

ISP routers don't implement Ingress filtering since they don't know in advance which IP addresses are valid inside a given network target.


Truecrypt, gpg or pgp would seem to do the job for you.

Encrypted files, folders or separate filesystems - piece of cake. You can configure how long you want them to cache your passphrase before requiring it again.

I would however recommend screen locking every time - it does a lot of good, and in your particular scenario it would definitely help you minimise the threat from your friends.


Identity management in a mixed Linux/Windows environment

Microsoft Active Directory can be used out-of-the-box for macOS and certain enterprise ready Linux distributions (e.g. Ubuntu). There is no customization required.

macOS has a feature called Directory Utility.

Ubuntu's feature to support Active Directory.

The company I work for has a similar scenario than what I've described above and it works as expected.


What are the security risks of importing and processing an excel spreadsheet from an untrusted user

While Austin is correct, it is also a risk that the file itself contains an exploit. Office applications are utterly massive and have a truly humungous attack surface area. If you have time on your hands, open up an instrumented fuzzer like American Fuzzy Lop (AFL) and run it on your Excel processor. You will find a stunning amount of very scary-looking crashes.

You have to assess your risk here. If you are defending against someone who only has the skills to write a malicious macro, you probably don't have much to worry about. If you are defending against someone who knows a thing or two about software exploitation and you are their target, you opening their spreadsheets will be a dream come true.


Integrity of LIVE forensic evidences (e.g. memory dump)

Disclaimer: I'm not a lawyer, so my advice is not binding.

There isn't a failproof way to keep memory in a specific state.  Yet, there is a way of arguing that a memory dump can be reproduced and/or argue that you can tell which parts of the memory may have changed.

Proposed tactic

The moment you are making a full memory dump, several processes are running and a kernel is scheduling them.  And, moreover, it is possibly swapping memory pages between physical memory and a disk area (swap).

So the first thing you need is to get the memory dump and the swap are at the single point in time.  Second you need to get the state of the CPU registers (I'll come back to it in a moment).

I'm thinking in terms of a Linux machine because it is the OS I'm most familiar with.  For that OS you can dump /dev/mem and dd the swap areas, or use something like LiME.  For other OSes the are several alternatives.

Now, to be able to argue that the memory dump can be reproduced you will need to find and analyze the Global Paging Table (PT).  That table resides in memory and links memory access by the kernel onto the actual parts of memory.  The location of the table should be in a register (register CR3).  But this is why you need the registers, all of them not just RAX, RBX, RCX, RDX, R5, R6, RSP, etc), so the CPU unit responsible for paging can access it.

It is viable to argue that if you can make an index of the PT you can tell which part of the memory may get updated.  How?

The PT holds pages in the physical memory and on the swap too, so your index covers the entire memory.
DPL (part of the PT) will tell you which pages are owned by the kernel and which are owned by user processes.

Now, based on what the machine does you can tell which memory pages may have been affected and which don't.  For example, connecting a pen drive (assuming that the machine does not perform clever udev rule or similar) should only change kernel pages (well, almost, virtual filessystems, e.g. /proc would also be updated).

Pessimistic reality check

Unfortunately, most OSes today will run daemons that will periodically scan userspace visible part of the kernel and act upon it.  Possibly messing userspace (DPL 3) pages considerably.  You will definitely need physical control of the machine, and analysis of what happens (userspace-wise) when you do something to the machine.

Optimistic notes

On the bright side, when you have the memory dump divided into pages, you can reproduce the sate of the machine (to a good extent).  For example, you can boot a VM, start a kernel debugger and overwrite all memory pages one by one.

How that would be seen by a court, may still depend on more classic forensic points.  For example, how do you prove that the memory dump in question is of the machine you claim it to be.  But that is something that can be solved by procedures that document exactly how the forensic was performed on the machine.

References/Related

Forensics Wiki - Memory Imaging
How to dump memory in Linux - unix.SE
There is a digital forensics tag on law.SE I believe that the most relevant answer there is: Can data from computer forensic investigation be denied as evidence?.  They argue about chain of custody.


PGP/MIME (RFC 4880 and RFC 3156) is (in my humble opinion) the least intrusive way to PGP-sign mail. It puts the signature into an attachment of type application/pgp-signature using the filename signature.asc, which some email clients will be able to verify and others will at least recognize that it's a cryptographic signature.

However, if you control your server, you could consider using something more broadly adopted: DKIM and DMARC.
DKIM (DomainKeys Identified Mail, RFC 6376) signs your message body as well as several headers (typically From, Date, To, and Subject). Keys are served via DNS and signature verification is decently universal as this (alongside DMARC) is a key defense against spoofing attacks like phishing and Business Email Compromise (BEC).
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) sets a policy: what to do when an email fails to verify its DKIM signature (note, it also must fail SPF, but you can mandate DKIM by setting an SPF record of v=spf1 ?all to permit nothing). DMARC can instruct servers to quarantine or reject non-compliant mail. It also has reporting built in so you can observe what mail might be inappropriately blocked.
This ensures all mail sent by your server is cryptographically signed, that it's verified by nearly all recipients, and that you can instruct recipients to block or quarantine mail that isn't provably from you.


How can credit cards be encrypted and still be recalled later?

I think you are confusing encryption with hashing because hashing is one way whereas encryption is two-way providing you have the proper key to decrypt whatever is encrypted.

Short answer is: they are storing the key somewhere (in a hopefully secure location). Whenever they need to decrypt the credit card number they hand the encrypted data to a module that looks up the key, decrypts the card number, and returns the card number to the payment system.


How to handle UDP abnormally disconnection in DTLS？

As commented by dave_thompson_085, DTLS is connectionless.

In order to detect a client which has stopped communicating you would have use a method of detecting a client is no longer sending traffic, such as a heartbeat or keep alive. RFC6520 was written exactly for this purpose.

The reason it's not in the DTLS RFC is because the protocol is connectionless by design.

It's also worth noting that although Heartbleed was a bad bug, it's now been patched and it shouldn't discourage you from using OpenSSL. There are also OpenSSL alternatives such as LibreSSL

(Note: I would have put this as a comment but I don't have enough reputation at the moment)


This is a common problem with Google Analytics and is called ghost spam/referrer spam.

They only send a request to your Google Analytics key (UA_XXXXXXXXXX), and the bots doesn't hit your website at all. They do this using the Measurement Protocol which allows developers to send raw user interaction data directly to Google Analytics servers.

The only real problem you will experience with this is the fact that it's annoying, and without filtering your analytics it may mess up your results, graphs and metrics.

There are multiple guides on how to hide/remove such spam from Google Analytics, for example this.


UserDataSvc_6038b: unable to disable this suspicious service

If you're genuinely concerned that this service is/was malicious, there's a few things you can do:

Check the properties on the DLL listed.  Is it signed?  By whom?
Upload the DLL to VirusTotal.  If you have the same version as another source, you'll get this results page that shows 0/57 detection ratio, and an author of Microsoft corporation.

I don't have a Windows 10 box handy to check myself for the DLL in question.

If you search just for 'UserDataSvc', you'll find lots of other people asking about a service with that name + 5 hex characters.  Likely Microsoft has done something to make a unique service.  (Maybe it runs one per user on multi-user machines and 6038b is related to your account?  I doubt it's part of your SID...)

Just from reading about it, I'm fairly confident this is a benign (well, intended by Microsoft) service.


Email header field "From" : angle brackets + square brackets

If it was straightforward to create a rule to block this, then every client would do it - the problem is legitimate mail re-senders, like constantcontact, mailchimp, etc. would be blocked, too. Even tech support departments use this technique.

In short, you could do it, but you probably wouldn't want to.


How to secure MySQL server for the case of hardware theft

Suggestion to your problem:

Make sure the timezone is configured correctly and that you run ntpdate/ntpd on your machine to keep the time in synch.
Apply iptables rules based on time and day.

iptables -A INPUT -m time --timestart 07:00 --timestop 19:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT

For GeoIP support with Linux netfilter see: https://daenney.github.io/2017/01/07/geoip-filtering-iptables.html

On another note I'd suggest you to enable Google Authenticator (phone/push notifications) or Yubikey integrated with PAM, to achieve a multi-factor authentication scheme.


Let's take a look at the Android Developer docs "Android keystore system". We'll need to break this down depending on how you use the KeyStore object. If you're using the Android KeyStore KeyStore.getInstance("AndroidKeyStore"), then:

1) If the device the app is running on has hardware-backed secure storage, then

  Key material may be bound to the secure hardware (e.g., Trusted Execution Environment (TEE), Secure Element (SE)) of the Android device. When this feature is enabled for a key, its key material is never exposed outside of secure hardware.

The "Android keystore system" article gives more info on how to use this feature.

2) If the device does not have hardware-backed secure storage, then:

  Key material never enters the application process. When an application performs cryptographic operations using an Android Keystore key, behind the scenes plaintext, ciphertext, and messages to be signed or verified are fed to a system process which carries out the cryptographic operations.

Presumably this system process is written in C where they have more control over memory management and can zeroize the key properly when it goes out of scope in your application (which leads me to my rant about garbage collectors...)

3) If for some reason you use KeyStore.getInstance("JKS") as in the examples here - maybe you need access to the private keys for some reason, or you need to load / store the private keys in a .jks file - then No, you can not wipe it: because the Java garbage collector is famous for returning memory to the OS without clearing or zeroizing it. From the Android developer docs, I don't see any evidence that the Dalvik garbage collector works any differently.

Moreover, one of the mechanisms of the Java garbage collector is to make a copy of any heap variable that's currently referenced by your program and then free the old heap. This means that a copy of your private key may be freed back to the operating system even before it goes out of scope.

Bottom line: If the Android KeyStore object is used properly, your private keys will remain securely inside the Trusted Execution Environment (TEE), Secure Element (SE)) or System process.

If for some reason you do bring the private key into your app, then all bets are off because in Java / Dalvik / Android, once something is in your app's memory, it is nearly impossible to clear or zeroize it.


I'm going to assume that you are talking about HSTS.

HSTS is TOFU (Trust on first use). So from the second use onwards, you are protected.

But what about that first use?

I don't think there's a unified strategy. But here's some ideas:

What works today

HSTS Preloading: Use a browser that makes use of the HSTS preload lists. (Chrome, Firefox) And hope that the developers of the website you want to visit have had their website listed for HSTS preloading..
HTTPS Everywhere: There the EFF's HTTPS Everywhere project that uses a browser side plugin (Chrome, Firefox) and a large list of redirect rules, to redirect plain HTTP requests to encrypted HTTPS sites. This plugin only works if a rule has in fact been created for the website you want to visit. But -- other than HSTS pre-loading -- this does not depend on the webmaster's cooperation. Rules can be submitted by anyone.

What might work in the future

DANE/DNSSEC: DNS is a general purpose vehicle for storing info about domain names. Wikipedia's article about HSTS hints that this might be used in the future to indicate HTTPS support. -- "DANE" is a mechanism that uses DNSSEC (the signed form of DNS) to communicate crypto info about a domain name. For example to say "only this CA may sign my HTTPS certificates". This is achieved by placing something like this record in your DNS server:

_443._tcp.www.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )

Now this tells anyone (who cares to ask) that a specific crypto key is associated in some way with a service that's running on port 443 on www.example.com.

Now a human can easily guess: "Okay, 443 will probably be HTTPS", and then connect with HTTPS instead of plain HTTP. But what you can't deduce from an existing DANE record is that HTTPS is fully supported for every bit of the web site. (For example HTTPS might only be used for login to that site and not work for the rest of the site.)

But AFAIK there is no mechanism yet to communicate "Use HTTPS!" to a browser.


Rest WebService with signed requests in Java

First, the nonce you get from the web service must be cryptographically secure (unpredictable) and used only one time to avoid replay attacks.

Then, there is nothing wrong with this approach, as soon as the web service stores the public key from the client and is able to verify its authenticity.

Moreover, one drawback to consider, is signature verification performance cost. (see: Statistical data about the performance of various encryption algorithms)


What does Technical Constraint and Organisational Constraint mean in terms of Internet Security Management

A technical limitation could be lack of processing power to perform a specific task, for example if you work for Yahoo Mail and you can't digitally sign every email then this can be seen as a technical limitation.

An organisational limitation could be not being able to use smart cards because the company culture does not allow such an authentication mechanism


Is it true that encryption bit "strength", although numerically identical, may actually be different depending on the algorithm?

The general point of cryptography and enciphering of information is to increase the difficulty for anyone other than the intended recipient to retrieve any part of the information (or data) in transit or in storage.  Increased difficulty makes it less likely that an adversary will be able to make sense of any part of the enciphered data.

What many people take for granted is how time influences the value of data.  Data (information, secret recipe, etc) generally loses value over time.  For example, corporate merger communication is generally seen as more valuable today than after the fact.  With that said, there are data that does not lose significant value over time.  In such cases, the relative strength of the cipher becomes another variable for consideration.

The strength of a symmetric cipher can be tied to several things.  Key size is one that most people understand.  For example, DES uses 56 bit keys, AES has several flavors (128, 192, 256).  However, key size is one component of the strength of a cipher.  The implementation of the cipher is also an important consideration.  Additionally, implementation details also factor in.  Block ciphers and stream ciphers are both modes of operation for a symmetric cipher and there are weaknesses that affect different modes of operation.  Additionally, adversaries can attack the implementation of a cipher and reduce its effectiveness.  TDES providing 112 bits of security is one such example.  AES 192 is another example due to the implementation of key expansion function.

A good illustration of a cipher where key size doesn't correlate to strength can be seen with asymmetric ciphers.  Most asymmetric ciphers are based on the RSA algorithm with common key sizes of 1024 and 2048 bits.  ECC is a newer cipher with much smaller key sizes than used with RSA.

So there's no one measure of the strength of a cipher and the passing of time usually renders ciphers less useful.  As time passes, there will likely be additional attacks against current ciphers that render them less useful.  However, even if no such attacks are successful, as technology improves, brute forcing the cipher becomes more affordable and a new round of algorithms to protect data will be developed.

Hashing is a completely different function than encryption.  With encryption, you want to be able to scramble the data but still have the ability to unscramble it at a later point.  Hash produces a fingerprint of the data and is used to demonstrate message integrity (i.e. contents have not been changed).  A hash of a data (SHAy, MDx) usually accompany the data itself.  An email message might come with a hash such that the recipient can validate the message has not been altered.  The message can be visible to anyone in-transit or in storage.  There are other uses for has values alone (DLP, AV, FIM), but adversaries are more interested in how to modify the source data to produce the same hash value - to bypass message integrity.

Though larger output bit sizes may increase the difficulty of a collision, it may become possible.  For example, if the email authorizes a contract at $100K but you're able to change the 'K' to an 'M' and still retain the same hash output, you've defeated the value of the hash (someone was able to tamper with the message and you weren't able to determine that someone did tamper with it).  As with encryption, an adversary can attack the hashing algorithm, or the passing of time and increases in technological sophistication may make collisions more common.  At which point, there will be a new round of algorithms.


I'd say Debian gets away with it for several reasons.

People don't know this security features exist and therefore don't demand them.
People expect Debian to be secure and don't check if it really is.
If your packages are up-to-date and patched for vulnerabilities, PIE and ASLR help very little, except against 0-day exploits.
Most people don't care about high security.

I've been using Debian on my servers for more than 10 years now and because of this lack of security on their part (among other reasons) I'm migrating to CentOS 7 when it's released in a few months.


What additional protection does seccomp provide when compared to capabilites?

Seccomp and capabilites serve different purposes, for starters. Capabilities are used to add slices of root privilege to an otherwise unprivileged process. By contrast, seccomp removes the ability to perform certain functions by taking away normally-available syscalls.
You don't need special privileges to perform syscalls normally, as syscalls are the mechanism through which an unprivileged user program can open files, network sockets, devices etc. There are many use cases for seccomp; perhaps you want to sandbox your program from the filesystem or the network. Or perhaps you simply want to lower the attack surface for privilege escalation by disabling unneeded syscalls.


What to do after being phished for address, DOB and NI number?

National Insurance number suggests you are UK based. For protection from financial fraud you would go for protective registration with CIFAS and ask the three credit agencies (Equifax, Experian and Callcredit) to put notes on your files that all loan applications should be checked with you.

Most serious identity matters which do not use credit agencies will ask to see photo-id proof such as a passport or driving license. For passports these are hard to replace without holding the previous document - it often involves being called in for an in person interview - which offers some protection against fraud. Obviously if you have never held a passport before there is higher risk. Driving licenses are easier to obtain fraudulently. However the DVLA will use your passport photo if available - so it is still difficult to obtain one with an image of someone else.

Other nations have other systems. But in most places there is some form of credit agency which can be notified. Some countries (Estonia for example) use electronic ID cards.


Are MITM attacks possible on HTTP loopbacks?

The problem is all in accessing the server and gaining a suitable privilege level.

update: and of course if you have such an access, you can probably take control directly of either the "server" or the "client", or both, or covertly access their same data unbeknownst to them. No need of a man in the middle if you're the man inside.

But say you have root there... then, yes, you can mount a MitM attack even if you can't use anything but the loopback interface for whatever reason, and cannot otherwise interfere with client's or server's operation.

All you need is lovecalhost duplicating its address to something useable, and telling the victim that example.com maps to that address.

Practical example using a service I have listening on localhost port 631 - cupsd. A webserver would listen on port 80, but everything else stays the same.

netstat -napo | grep LISTEN | grep -F 127.0.0.1
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1321/cupsd          off (0.00/0/0)
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      1721/named          off (0.00/0/0)
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1721/named          off (0.00/0/0)

Now I cannot listen straight away on the chosen port since there's a legitimate process already there:

# netcat -l 127.0.0.1 631 &
[1] 26264
netcat: Address already in use
[1]+  Exit 1                  netcat -l 127.0.0.1 631
#

But nothing stops me from creating another loopback interface (lo:0 instead of lo) using aliasing...

# ifconfig lo:0 127.0.0.42
# ifconfig lo:0
lo:0      Link encap:Local Loopback
          inet addr:127.0.0.42  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1

and telling the system that example.com is indeed 127.0.0.42 by manipulating the hosts file (if the DNS had priority, I'd tweak its zone file)...

...and now I can listen (in this case to a single line)

# netcat -l 127.0.0.42 631 &
[1] 26442

and if I send that line, my listening netcat receives (and could reply):

# echo "Hello" | netcat 127.0.0.42 631
Hello
[1]+  Done                    netcat -l 127.0.0.42 631
#

Nothing has traveled outside the loopback interface (except that of course how am I inside that box if it has only a loopback interface?), and if the connection goes to "example.com", the server has no way of knowing the connection is being hijacked.

I could try and do this even without aliasing, but the required procedure would heavily disrupt communications and might not work always, or even at all, since I cannot easily prevent client and server from hearing one another.

(The aliasing I did here is just a proof of concept, and would probably cause havoc down the line - just consider I have now 127.0.0.1 and 127.0.0.42 on the same "trunk" and they both have /8 masking)


Broken/halfbaked security with this implementation?

This is roughly the same mechanism as SSL, with the exception that it lacks a verification step for the RSA public key he sends you. SSL has a whole PKI involving certificate authorities and signing in order to ensure that the public key you get actually belongs to the party you're communicating with. If his cipher doesn't include it, then you're definitely susceptible to man-in-the-middle attacks.

And if it does include it, then you're more-or-less using a primitive SSL, in which case you should be using real TLS (version 1.2 if you can swing it) which includes defenses against additional more difficult attacks which a custom-built protocol probably won't have.


Is it possible to create a pem file server certificate from the result of openssl s_client -showcerts?

IF your curl was built to use OpenSSL -- as you tagged but which is not the only option for curl, verify with curl -V -- AND the server is correctly serving any/all intermediate cert(s), THEN to trust the server curl-with-openssl needs a local 'truststore' containing the root cert for the server's cert chain (NOT the server's cert itself) in PEM format. (Some other SSL/TLS implmentations will accept nonroot anchor(s), but older versions of OpenSSL cannot do so at all, and even 1.0.2 doesn't  do so by default.)

METHOD 0: maybe already there. Packages of curl often include a 'bundle' of widely-trusted CA roots such as Symantec GoDaddy etc., or link to another package that does (typically named something like ca-bundle or trusted-cas). The format(s) of the certs in such a bundle depend on the SSL/TLS library(ies) you use; check curl -V as above. Check if you have such a bundle installed, and if so whether your curl is using it. If you don't have or can't get a package (including the case you build curl yourself) AND use OpenSSL, curl upstream has a bundle of CA roots extracted from Mozilla NSS/Firefox extracted into the concatenated-PEM format needed for OpenSSL (and a tool to do this yourself).

openssl commandline need not use the same default truststore location(s) as curl -- and even if it does, until recent versions the s_client command had a bug that didn't use the default truststore correctly. If you do have a concatenated-PEM bundle, specify it to s_client with -CAfile bundlefile and see if that makes a difference.

If method 0 doesn't apply, you need to get the server's root and add it to your truststore, or just use it as a truststore by itself.

METHOD 1: get from browser. IF you can connect to the server with a browswer like IE/Edge, Firefox, Chrome, etc. (this requires there be a URL you can enter that the server will respond with a successful webpage), THEN doubleclick on the padlock and click on whichever buttons or links lead to displaying the certificate chain (exact ones vary per browser). Select the topmost cert in the chain and look for an option to export it, preferably in single-cert PEM format (again exact method varies per browser). If you can't get single-cert PEM format, comment what format you did get (give the first line if it looks like -----BEGIN something) and I'll tell you how to convert it.

Take this file (copy to the curl machine if you created it somewhere else) and either add it to your truststore (depends on your packaging system; may be a simple as concatenating it to the existing concatenated-PEM file) or specify it by itself to curl with option --cacert filename.

METHOD 2: s_client plus. Run openssl s_client -connect host:port -showcerts and capture (redirect or scrape) the output. Take the last block of lines -----BEGIN CERTIFICATE----- to ----END CERTIFICATE----- and put it in a file, for example topcert. If the s: and i: names (subject and issuer) immediately preceding this block are exactly the same, this is the root cert and you're all set. Use this file as above, but only if you are satisified this CA is honest and competent (even though they apparently didn't convince the browser makers if method 1 didn't work) because you are putting the security of your data in their hands.

If the top cert from the server is not a root, you need to get its parent cert, which must be the root. Alternatively, in some cases this is a 'bridge' or 'transition' cert that links a new CA back to another (older) CA, and there is also a sibling cert for the new CA that is a root cert. First do openssl x509 -in topcert -noout -text and look under x509v3 extensions then Authority Information Access for CA Issuers. If present, accessing this URL (or any of them) should provide the parent cert. This is usually in DER format; if so convert with openssl x509 -in input -inform der -out output.

Otherwise, look at any OCSP address(es), any CRL Distribution Point(s), and any URL(s) or domain name(s) in Certificate Policies or the Issuer name for the domain name(s) used by the CA and poke around there to try to find the parent root. Similarly look at any URL(s) or domain name(s) in Policies or Subject name and poke around for a sibling root. Or google for the Issuer name and/or Subject name. Or post the cert here. Or some combination.


How can access to settings of a public router be (mis)used?

Just a brief list of some fun possibilities:

Hog all off the WiFi Connection by kicking everyone off. Kick everyone else off in a number of ways, changing password to WiFi and to the router to prevent wired users, then block everyone but your MAC address. I wouldn't suggest this though because the owners may notice a lack of wireless internet and go and reset it.
Provide a captive portal page that looks like Google to steal credentials
Provide a captive portal page that take you to a drive by or provides a hook
Set all DNS traffic to a DNS server you control to point all bank traffic to spoofed banks to harvest credentials.
If a remote firmware update is available then have malicious firmware updated to allow a whole set of Man in the Middle attacks to happen
Logging all packets coming in and through, pick up unencrypted traffic*

These are just a few I can think of off the top of my head
*Probably can't be done without flashing firmware or a more advanced router


Can SSL be used to encrypt non-HTTP data?

Can we use SSL/TLS to encrypt the protocol's payload without tunneling it through HTTP?

Absolutely.
TLS provides secure communication on top of the transport layer and you can easily employ it as a transparent wrapper around your own custom protocols.

   One advantage of TLS is that it is application protocol independent.
   Higher-level protocols can layer on top of the TLS protocol
   transparently.  The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

(from RFC 5246 for TLS 1.2)

HTTP just happens to be one possible application-layer protocol that is commonly transmitted over TLS. There are many other examples where TLS is added to secure a protocol that has no built-in encryption. E.g., if you use a desktop email client, the communication with the mail server (probably using IMAP/POP3/SMTP) will likely be wrapped in TLS, too. TLS can also be used as an encrypted tunnel for the entire network stack for VPN applications (although OpenVPN only uses TLS for authentication, not for for encrypting the actual data - thanks, @ysdx).


VLC Player / Faststone Image Viewer / Faststone Video Capture are totally safe right?

Bugs resulting in security problems in video or image processing applications happen regularly and happened in the past at least with VLC too. Apart from that it is unknown from which source you got these applications so they might be infected with malware. And this can also happen if a trusted download source was compromised.
In summary: It is not totally safe and there is probably nothing like total safety at all.


How does a client's web-browser know if a website is HTTPS only?

A client's web-browser would know if the website is "https" only by checking if the website is listed in it's HSTS pre-loading list.

As you mentioned, in a classic scenario, a MITM could intercept an http GET request and prevent the redirection to the https version of the website.

This is why HSTS pre-loading was invented : browsers can verify if the visited website is in its HSTS pre-load lists. If it is the case, it will query the https version immediately, without trying the http first. This mitigates the MITM scenario


What would it take to scan a PDF for questionable content in addition to malware?

There are a few frameworks that come to mind for this. Mastiff, Viper, and IRMA. All are meant for reverse engineering, and analyzing malware so any will need some customization to run. For example:

Out of the box install:

client  --> uploads file to system
system  --> system sends it to one of the above
program --> analyzes file creates report

You would need to do something like the following:

client  --> uploads file to system
system  --> system sends it to one of the above
program --> analyzes file if malicious delete/quarantine/etc
program --> analyzes file is not malicious send file to your org

This can be done with some work otherwise this becomes a "vendor" specific question: "What product can..." which is off-topic here.


How do you protect strings in code from users decompiling them and seeing them

In short: you can't.

As long as someone has the local copy and the local copy is capable of retrieving this key, then someone could reverse engineer and get it. If someone had attempted to hide or obfuscate their code, then I would just step through the program in real-time or through IDA Pro. If at some point you store your key in a variable, then I'll grab it in memory. If you rely on some sort of algorithm, I'll reverse-engineer a working version by looking at how you do it.

Let me give you an example. There exists an RSA key on the Xbox 360 console to secure content made on the console such as save games. Both the private and public keys were stored in the kernel, and the RAM was completely encrypted. It took a long time, but someone was finally able to reverse-engineer the kerner enough to know the entire file structure, how the SHA blocks were created, and able to grab the RSA private and public keys. It took significantly longer since the system was secure, but they were still able to get it. From Microsoft's own console.

The only true way to hide something is to do the work on something you trust, aka the server.


You are basically correct.

  Also, is it usual to have action in row 3 in real life?

Yes, if the intent is to only allow packets to your web server, you have to deny everything else.  Many types of ACLs have an "implicit deny," meaning that if the packet doesn't match any ACE, it is denied.

  what is the importance of the ACK bit in the flag field?

The ACK bit is set on established connections.  The reason to filter on it is to prevent incoming TCP connections.  That is, only connections started from the inside are allowed.

  Why is no state being one of the drawbacks of Packet Filter?

Having state information allows you to enforce TCP protocol rules, which better protects your servers.  The disadvantage is when you have multiple paths, you can have asymmetric flows which a stateful device doesn't handle very well.

Perhaps it's just the way your rules were written for this example, but a good practice would be to specify the IP addresess on the inside, instead of a generic range.


what prevents sending "$.post" from one domain to another?

The --disable-web-security flag will prevent Chromium from enforcing the same-origin policy (SOP), which will allow you to read the response of your cross-origin POST request.

However, do note that the POST request is always sent, regardless of same-origin policy. Anything that takes place on the server for that request will still happen (creating a resource, updating something, etc.) This is what is meant by cross-domain writes are allowed:

  The simplest explanation of SOP is that Origin “A” has the following permissions:

  Read of resources from Origin “B”: Deny
  Write to Origin “B”: Limit
  Execute of resources from Origin “B”: Allow

Source: https://blogs.msdn.microsoft.com/ieinternals/2009/08/28/same-origin-policy-part-1-no-peeking/

More explanation about "limited write" can be found on part 2 of that blog post.

Mozilla's documentation also explains it well, using different terminology. (jQuery's $.post uses XMLHttpRequest)

  The same-origin policy controls interactions between two different origins, such as when you use XMLHttpRequest or an <img> element. These interactions are typically placed in three categories:

  Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
  Cross-origin embedding is typically allowed. Examples are listed below.
  Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Source: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access


How to decide to use, then how to use an http gofile.me url in an email, explained to a five year old?

The idea is that the document is evolving so the link will provide the latest version, but should I insist the colleague email me the document directly?

Having a link or having the file directly does not actually make much of a difference. The link can point to some malicious file or to some phishing page (i.e. stealing of passwords) but an attached file can actually be malicious too - especially Office documents with macros enabled. And such malicious links and attachments are unfortunately fairly common today.
The question is thus if you trust the sender and if the sender is actually the one you think it is. Unfortunately the sender of an email can be easily spoofed, similar on how could simply write a faked sender on the envelope when using snail mail. Or the sender might also be hacked and the trusted account used to send mails.
Thus, when in doubt about the origin and intend of the mail, better contact the sender to confirm that the mail was actually send by them. Such contact can be using a different communication channel (phone, messaging, asking personally, ...). If you can be sure that the sender was not hacked you might also ask for confirmation by email. In the latter case you should make sure though that the address you reply to is actually the email address you know from the sender, and not the address of an attacker.


Devising encryption schemes and protocols

Cryptographic algorithms are complicated beasts where every single detail matters for security. Unfortunately, cryptographers do not have a simple test which can tell whether a given algorithm is secure or not. It is unknown whether, in a mathematical sense, such a test could exist at all; and, even if it exists, we have not found it yet. We do not even know if secure algorithms can exist in general. Decades of cryptologic research has come up with a lot of partial solutions, such as "security proofs" which reduce some problems to other problems (e.g. a proof that the Rabin cryptosystem cannot be less hard to break than integer factorization -- which does not imply that integer factorization is hard).

So the normal methodology is to have some cryptographer publish a proposal, and let others try to break it and then potentially fix it. When an algorithm has been subject to such external scrutiny for some years and still survives, it is deemed "usable".

The case of RSA is a good illustration. Its mathematical description was first published in 1977, but it was only the core principle, with the modular exponentiation. To turn that into a secure algorithm for asymmetric encryption, or a secure algorithm for digital signatures (not the same thing at all), one must add some other elements, including random bytes, hash functions and behavioural constraints (e.g. whether it is good or not to report a "bad padding" error upon decryption). A number of hastily slapped together proposals turned out to be unsatisfactory. After a long trial-and-error process, RSA (the company) produced PKCS#1 v1.5 in 1993. This standards tells you exactly where each byte goes, including hash functions and random bytes. Although it seems rather sturdy, it turned out, in 1998, to have a weakness which could reveal the private key if the implementation, upon decrypting data, was too talkative about error conditions, when decryption fails.

This prompted new versions of PKCS#1, v2.0 in 1998, v2.1 in 2002, and v2.2 in 2012. What v2.0 describes appear to be robust for encryption; v2.1 extends it for signatures, and v2.2 adds some glue for newer hash functions. Not that a properly implemented PKCS#1 v1.5 would be weak; but the newer versions (called "OAEP and PSS paddings") benefit from partial security proofs (which, by the way, took time to be actually proven; the first published proofs were later found to be erroneous).

This is how algorithms should be designed: with years of effort by people who are specialized in the subject. The lack of reliable test for security means that we have no better way, and even spending 20 years on a single widely-used algorithm does not guarantee that every problem was detected.

In parallel, there are a lot of people, in the computing industry, who do not follow this methodology. Instead of waiting for well-studied algorithms to be turned into standards, they just go ahead and slap together a few primitives, sprinkling hash functions and other elements in a seemingly random way. Their guidance is a few very vague notions of security (often badly misunderstood) and whatever they will find in other people's blog posts.

This is why you will observe, in practice, a lot of "homemade schemes" where some developers just went way too much creative. Almost all of these schemes are weak and breakable, but the exact reason why they fail depends on the context.

Why many developers act that way is a mixture of arrogance and ignorance (often more ignorance than arrogance), and the primary cause is that special property of security: you cannot test for security. This is what makes security, and in particular cryptography, quite alien to most developers: it operates differently than all other fields. When you write a Web site or a graphical application which does 3D rendering or an accounting system, you test for functionality: you check that things work as expected when faced with normal situations. In security, you must test for non-functionality: you must check that things fail as expected when faced with abnormal situations. The virtually infinite set of "abnormal situations" makes the usual Q&A processes utterly ineffective for security.

The best we can do is "spread the word", as this present message tries to do: don't do homemade crypto.

Summary: if you can give simple explanations of why a given assembly of the RSA modular exponentiation and hash functions yields an "obviously secure" algorithm or not, then you are due for a PhD or even a Turing award.


Is my network infected? Suspicious messages and devices slowing down

One of the helpful things in this situation is a knowledge of the OSI model and the layers of technology. OSI layers can be extremely boring to study in school, but they, and an understanding of technology stacks in general, form the basis of almost all understanding of the interrelationships of technology. And that understanding will help you troubleshoot things like this.

Networks do not infect anything. Networks are connections between nodes (computers, phones, routers, etc.) So, if there was malicious code lurking in the network to infect new things, it would have to exist on one of the nodes. You replaced the router, so that's not it. Your phone was new to the network, so that's not it. What's left is everything that is left. His computer and anything else that is a node on the network (TV? Game consoles? Other IoT?). The laptop was formatted and rebuilt, but the malicious code could have been reintroduced when things were reinstalled.

There is nothing in your description to suggest that your phone was infected at all. It received a message. How you got that message is a good question, but you need to provide more details so that there can be an understanding of what layers are involved. If you got a pure SMS message, then the message is a coincidence. There is no technology overlap between WiFi and SMS.

The steps you need to take is to work through a basic troubleshooting process to eliminate the various elements of the problem. You need to understand the connections between the various technologies and trace the behaviours from one technology to another.


How can I report an ecommerce site in violation of security practices?

The following questions on this site may be of interest:
Best way to alert a website owner of a vulnerability?,
How to disclose a security vulnerability in an ethical fashion?,
Reporting vulnerable sites.

Here are some security contacts for some of the companies you named:

Paypal: sitesecurity@paypal.com  (really intended primarily for security issues in the Paypal site, though, not third-party sites)
American Express: Amex Enterprise Incident Response Program (EIRP): 888-732-3750 / EIRP@aexp.com.  (really intended primarily for merchants to report a security breach of their systems, though, not for fourth-party reports of vulnerabilities in third-party sites)
Google: security@google.com (really intended primarily to report security problems in Google products, though, not third-party sites)

Be prepared that most likely none of these parties will act on your complaint.  If I were you, I'd report it to the site, and if they brush you off, well, you've done your duty and there's not much more you can do -- apart from taking your business elsewhere.  Sucks, but that's how it works.


Limit file access to admin and application on Windows 10?

There's no really easy way, I'm afraid. The assumption in most of computer security, dating clear back to the first multi-user systems, is that anything a program running under a user can see, then another program running under that user (such as Notepad) can also see. This has been changed somewhat by the introduction of app sandboxing, but all that does is let you make it so some specific program(s) can see less than other programs; it doesn't give them the ability to see more.

To do this, you'll need to create a new account (or use the Administrator account, but that's needlessly dangerous) for the program to run in, and then create a way for a non-admin user to launch that program as that user without being able to launch any other program as that user. On Unix-like operating systems that's relatively easy - the "setuid" bit in file permissions would let you do this - but it's harder on Windows.

Here's one way, if you don't mind doing a little work for each non-admin user and are using Win10 Pro or Enterprise (or other recent "Professional-or-higher" Windows edition):

Create the "SecureApp" user.
Set the app's config file to be full access for the new SecureApp user, but no access for anybody else (at least, any other non-admin).
Create a shortcut that uses the runas.exe program with the /savecred parameter. The full command will look something like this: runas.exe /savecred /user:SecureApp C:\path\to\the\application.exe. See this forum post for a step-by-step.
Run the shortcut once for the non-admin user, and enter the password of the SecureApp user when prompted.

The user can then run that shortcut to launch the program. Launching the program directly won't work, and you may need to do step 4 once for each non-admin user who needs access (even if they all log into the same computer and you put the shortcut on the all-users desktop or similar). Also note that the program won't have access to the user's own files or settings (more accurately, won't have access to the user's profile directory or current-user registry); if the program needs such access you will have to manually give the SecureApp user access to those items. Also, you need to make sure that your users never find out the password for the SecureApp user, or they can invoke runas themselves with some other program (like notepad) to go edit the config file.


If all you need to do is paste that link into the browser and you're redirected to http://security.stackexchange.com then yes it is a vulnerability.

The seriousness of the vulnerability depends on the expectations of the site and how much a user trusts it. If I can send some person a link to your site that contains a redirect to my malicious site, and they think "oh, that's important I need to click it" then its fairly serious. That redirected link can take them pretty much anywhere, which could lead to phishing, malware, etc., all the while the user thinks they're being taken to your site.


Detecting Spoofed InDesign File Creation Date

Systems that have been compromised cannot be trusted.  You can hope the attacker made a mistake, or missed something while they were wiping down their tracks, but in general, no, these aren't directly detectable.

First, identify your threat model.  In the kinds of organizations typically involved in data breaches, attackers often won't take the time to cover their tracks with precision timestamp tampering, because it's a lot of work to get perfectly correct.  Wiping their tracks gives them little benefit - once they whisk a copy of the data off to foreign soil, they no longer care about their tracks.  (While discovery time is improving, most breaches remained undetected for a month or more.)  In most cases they simply delete their logs, if they bother to do anything at all.  But I imagine a state sponsored attacker performing espionage would have more motive to operate stealthily to remain undetected for as long as possible.  So it helps to know your probable attacker.

There are things you can look for.  These could provide evidence of tampering, even though they can't be trusted to provide evidence of what really happened.

Look for inconsistencies in the timestamps.  The file's last modified datetime should not be earlier than the file's creation datetime, for example.
Look for file contents that are timestamped with values that don't match the last modified time of the file.  If the last line in a log file is stamped 2019-02-01 12:34:56, but the last modified time is 2018-04-20 16:20:00, that seems unlikely.
Look for other logs to corroborate program execution.  The Windows Event Logs may have audit history of processes that were run.  If it shows "2019-02-01 12:34:56 Accounting.exe terminated", and the Accounting.log file's last modified time is 2019-01-28 16:20:00, that would indicate the program was run but didn't log anything for the last few days, which might be unusual.
Look for multiple files that have no reason to be in sync that all have identical timestamps.  While I might expect tomcat-stderr.log and tomcat-stdout.log to have close timestamps, I might not expect them to have the same timestamp as accounting.log.
Check files that could contain unexpected timestamps.  For example, JPEG files can have metadata (called "EXIF") that can be viewed with an EXIF viewing tool.  Most phones and cameras will set the time the photograph was taken in the EXIF data.  If the last modified date of the image file is older than the date the photo was taken, it may have been tampered with.  Executable files may contain date artifacts from the linker; installation packages may have timestamps.
Look for evidence of hacker tools in the environment.  They may have run something like apt-get install nmap, which may be a clue as to when they performed their reconnaissance.
Check for logs on other systems the compromised system may have communicated with.  If the system is configured to export syslogs to a secure server, you would have a trustworthy source of when logins were made, applications were executed, etc.  External logging is a mandated requirement for certain security frameworks, such as PCI DSS, so it's not uncommon.
Look for gaps in logging.  If you see tomcat-stdout.2019-02-01.log, tomcat-stdout.2019-01-31.log, and tomcat-stdout.2019-01-28.log, you could reasonably wonder what happened to the logs from the 30th and 29th.

Keep in mind that any digital data could have been tampered with, and it could have been done so expertly.  Document what you find, but don't count on it to serve as proof in a courtroom.  If a system's been compromised, it's no longer trustworthy.


WPA2 is the only secure method. WEP and WPA are "broken". Also, WEP is easier to crack than WPA. However, any security, even WEP, is better than no security as it will effectively prevent opportunistic connections to your network.

I just checked and indeed the new Mac Books Pro don't have an Ethernet port. All I can say is WTF?!?


External network pentest and Application pentest. The same?

In short, no, they are not the same.

OWASP stands for open web application security project, which is why its guide is focused on the application side of things. You might find what you're looking for here:

http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

However, conducting pentests is best left for professionals - they will be more efficient and will be able to interpret the results correctly.


Reflected XSS in a JavaScript URL with some characters blocked

I have just completed this lab and have the same question as you do with regards to what is exactly happening around the JavaScript mentioned in your Question 1.

As per Question 2:

The & is simply a parameter separator since we are passing our user values via a GET request. This is esentially creating a new parameter named '},x with the rest of the XSS payload x=%3E{throw/**/onerror=alert,1337},toString=x,window+%27%27,{x:%27 as its value. This way the URL does not break, while the whole payload makes its way into the  anchor tag containing the vulnerable JavaScript URL.
The last part of the payload {x:' completes the remaining JavaScript code '}.finally... ensuring that our injected payload does not break it, but allows it to execute properly.


Court order and domain + hosting privacy

I'm not a lawyer, nor do I play one on TV. (you might want to consult a real one who specializes in this type of thing)

It seems to me that if you are just reviewing a product and giving your honest opinion then that is freedom of speech.

HOWEVER, if they have the resources and the will to do so, they can easily make at least some part of your life difficult, possibly threatening your host to the point where they play it safe and you get the shaft.

That being said, a third options comes to mind where you comply with what they ask (take down the content) and then you replace it with a new review that includes parts of the original review in addition to the reason why the original is no longer hosted on your site. Also you can perhaps have the original review posted on some other, much larger, site that is not your own and has a fair history of standing up for itself and its users successfully.

Posting that the reason your review is no longer visible on your site is because of legal action is something that they cannot complain about (because they literally caused it) and it also can serve as an even worse review than the first one (although I haven't read the first review).

I have not even mentioned your anonymity, because you have already gotten the notice by some method or another, so that means that there is a trail of breadcrumbs back to you already. However long it is, it exists. I personally would not rely on anonymity at this point at all if I were you, mostly because they might not know who you are now, but legal action could perhaps get them that information in the future.

PS: Good job for having a site popular enough to get the attention of the company you gave a bad review to in the first place.

EDIT:

To more specifically address your online anonymity, because it appears that this is the prime purpose of your question. I personally always go by the general idea that unless you took specific measures to be anonymous from the beginning (and at every step of the way) you are not anonymous while online (at all). And even then, if you have gone to great lengths, there is still little or no way to know if you truly are anonymous until someone looks hard enough to find you.


From personal experience it might be simpler to implement a keystone with a key that you only issue to the one user, vs. using the username/password authentication method, other than that I'm not sure what else you'd have to worry about. Maybe there is a way to combine both ways, but API's are usually set up so multiple clients can take advantage of the functionality, so a key might be the simplest way to restrict it to one single user.


Just post it on your website.

For most web services, your website is your identity. If you publish your public key on your website, anyone who visits it with a secure HTTPS connection can be reasonably sure that it belongs to you. If you publish it by any other means, you would need some way to connect it to your website to assure users that it is legitimate.


We can make use of MAC(Message Authentication Code) rather than just storing the hash of the passphrase in the DB.
MAC Generation
Once the key is encrypted, MAC is generated. We follow Encrypt-then-MAC mechanism.
You can generate a tag = MAC(m, k) where

m is the encrypted key
k is the key you use for encrypting the users' key (passphrase)

This tag is then stored in the DB instead of the hash of the passphrase.
Checking Passphrase
To check if the passphrase is correct or not, we can easily verify it by generating the MAC again in a similar way, with the key as the passphrase from the user. Now, the generated tag and the tag stored in the DB are checked, if they are equal.
If equal, it is a valid passphrase and the decryption of the encrypted key can proceed. Otherwise, we can throw a message to the user that the passphrase is incorrect.
MAC Algorithms
You can use HMAC (Hash based MAC) from OpenSSL for handling the tasks of MAC tag generation. Appropriate bindings would be available for whatever language you are using in your app.
edit: Make sure that a strong hashing algorithm like SHA256 or SHA512 is chosen for HMAC generation (and not MD5 or SHA1 as shown in the examples in the above link)


Malicious code found - translation please?

This code is obfuscated along with base64 encoding and gzinflating. You need to replace certain strings to get the proper encoded version of the script.

The script is using a key called pass and the attacker and later using the key and compromise your website. Its better to just rollback to your website if you have backup and then add a line to the header of the website to filter all special characters in GET & POST requests. The should stop attacker from injecting malicious codes.


Can a smartphone be hacked by calling it?

Very unlikely. I have never heard of an exploit in any cellphone operating system which can be exploited by taking a call from a malicious caller. If there were something like that, it would likely have made some news headlines, because it would be a huge vulnerability which would affect millions of end-users and would likely get widely exploited not just by criminals but also by juvenile pranksters.

It's not possible to prove a negative, though. Maybe there is some obscure vulnerability I have never heard of. But that's really nothing you should worry about unless you are a target which is so valuable that you are worth burning a zero-day exploit on.


It looks like it is encrypted using XOR encryption, with the key: 0x123f48233c3b2b150d5d097405097a30381e546240. When I decrypt the first few bytes of your message using that key, I get
ET Telefone de casa!!
I'm not sure what that means in Portuguese... But, here is what I did to decrypt the message:
First, convert the first few bytes of the message from base64 to hex:
echo -n 'V2tod1lXTnNiM2xUYWxaU1ltNUNh' | base64 -d | xxd -p

This produces:
576b687759574e7362336c54616c5a53596d354361

Now, use python to XOR this with the key 0x123f48233c3b2b150d5d097405097a30381e546240:
python3 -c "print (hex(0x576b687759574e7362336c54616c5a53596d354361 ^ 0x123f48233c3b2b150d5d097405097a30381e546240))"

This produces:
0x45542054656c65666f6e6520646520636173612121
Now, convert this hex to bytes, and ascii-decode the bytes:
echo -n '45542054656c65666f6e6520646520636173612121' | xxd -r -p

This produces:
ET Telefone de casa!!

By any chance, are you expecting a call from a famous 80's movie alien?


E-commerce website that uses plaintext HTTP but redirects to PayPal during checkout

Unless you are actually entering the sensitive information (i.e., credit card info) on the site itself, then you are fine. Think about it this way, say you're on the street, just outside of a bank. Everyone can see where you are, what you are doing, etc,. However, to make a transaction, you now go into some random transaction office in the bank. Clearly, no one on the street can actually see what you are doing, or even your exact location anymore. You complete the transaction, then come back and walk on the street, having completed your transaction. No one on the outside saw anything. Now of course some of the people on street might suspect that you just completed a transaction at the bank and target you for it, but unless you took the sensitive information with you to the street, then they won't be able to find anything. The street in this case is the random HTTP website that you are on, and the bank is PayPal.


Unless the network stack of your operating system has a serious security bug, just being connected to a malicious network should not allow the administrator of that network to install malware.

However, when you download software over the untrusted network and install it, and that download is not using https, the network administrator could perform a man-in-the-middle attack to infect the software with malware while it is being downloaded. When you then run the infected installer, it would install that malware.


From an infosec expert perspective, how secure is using Windows 10 as a daily os?

No

If you are fine using Fedora, keep with it. Really, some people would find a big change changing to Linux, but as you are already enjoying it, and assuming you don't have any hard dependency on a specific Windows-only application… I wouldn't look back.


Should IP addresses be validated to prevent SQL Injection?

You should use prepared statements to prevent SQL injections. Take a look at this question.

However, $_SERVER['REMOTE_ADDR'] should be a valid IP address as it comes from the server, as verified by the TCP handshake. See this question for an extended discussion on this.


What to do when one's server is being scanned very agressively

You can opt for protection from a scrubbing service by placing your applications behind a packet scrubbing service like Akamai or CloudFlare. These CDN's will take the hit for you normally before it reaches you.


Identify suspicious flood of SMS (phone exploit?)

It is your phone attempting to connect to facetime or imessage. You can turn this off if you wish. I don't like to assume, but my assumption here would probably be that there's nothing malicious going on.

Try this : If you get an error when trying to activate iMessage or FaceTime

As an aside: There's a lot on Google for this. It would've taken you a lot less time to google "REG-RESP?v=3", for example, than it took to write your question.


Triggering a XSS when the payload appears twice?

The following payload will work:

EUR66038'+confirm(1)+'820

Encoded version:

EUR66038%27%2Bconfirm(1)%2B%27820


Lastpass - Can I use my old master password to decrypt local data?

Sure fire way to keep a hacker from stealing your passwords off of device A is disconnecting it from the internet, then removing the malware.  If you want to be really safe, reinstall the OS.

That being said, your understanding is correct, the hacker could potentially decrypt your vault on the computer.


Which is better: detecting spam at receiver or source?

It's a classic for a reason:

Your post advocates a

(X) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(x) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
(x) Lack of centrally controlling authority for email
(x) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(x) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(x) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
(x) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Sorry dude, but I don't think it would work.


iPad stolen with LastPass, Should I be worried?

LastPass promises to that your password database can only be decrypted if the attacker knows your master password. So if you trust LastPass, you don't have anything to worry about.

However, given that LastPass is closed-source software, there is no way to actually verify this promise, and hence the security is based upon your trust in the company.

Still, given that you trusted the company enough to become a paying customer, there is no need to change any of your passwords. They simply cannot be uncovered without knowing the master password.


Received a Kindle from a stranger, what are the risks?

It is possible that the previous owner was one of these ultra-rich people for whom money no longer has any meaning, and he honestly believed that giving the Kindle away to the nearest stranger would be the easiest and most environmental-friendly way of getting rid of it.

It is also possible that the Kindle was some highly incriminating piece of hardware that the owner was anxious to distance from his own person in the swiftest possible way. The Kindle might be stolen, or might have been involved in hacking attempts, or might contain data of questionable legality which could direct the device holder to the nearest jail (e.g. pedophile pornography, which is highly frowned upon in most countries). If that is the case, using the device, storing the device, or even resetting the device contents to factory defaults might be the source of legal trouble.

The safest course of action might be to go to the nearest police station, tell them the story of how you got the Kindle, and leave the object to them.


Yes, it's possible - but not necessarily easy - for someone to listen in to your DTMF tones.

Land Line

This is the easiest to tap.  In increasing order of difficulty...

Anyone in your house can pick up an extension and listen to what numbers you press.
Anyone with access to your house can install a digital recorder into a phone socket and then listen for the DTMF tones.
Anyone with access to your property could attach a device to your phone line to listen in on everything you say.  Phone calls are not encrypted :-)
Anyone with detailed knowledge of your phone company could open your local cabinet and tap the connection there.

In short, typing in your password, credit card number, or any sensitive data, via a POTS landline is not a good idea.

Mobile Phone

Ok, let's assume that you've got a cellphone / mobile phone.  It's a lot harder to tap - but not impossible.

Anyone nearby will be able to physically hear the tones you type in.  Your phone's speaker will play the DTMF as you press the button.  A digital recorder, a microphone pointed in your direction, and some software to pick out the tones is all that's needed.
The connection between you and your base-station is usually encrypted.  However, there are known weaknesses in the encryption algorithms.  A determined attacker could, theoretically, decrypt your communications either in real-time or after the event.
It is possible (although difficult) for an attacker to force your phone onto a fake basestation.  At this point, the attacker can hear everything which you type in.

Are You A Target?

All of this really does depend on how high a value target you and your account are.  I doubt that your health benefits are of particular interest to criminals.

That said, if your bank account contains billions of dollars, and you use the same password for banking as for benefits - some of these scenarios are more likely than others!


How harmfull might be predictable bytes when using AES-CTR

What you are describing is somewhere in between a so called "known plaintext attack" and a "ciphertext only attack".

While these were (and sometimes still can be) a problem for older cryptosystems and modes of operation, in the recent history of cryptography cryptosystems and modes of operation are usually specifically designed to be resistant to such attacks.

There is currently no known attack (citation obviously not given) against AES-CTR in which (partially) knowing the plaintext results in a non-negligable advance for an attacker.

TLDR or TCDNU: Iff you use AES-CTR correctly, this should not be a concern. However, you might want to consider using AES-RCTR or AES-GCM. Especially the latter has many advantages, two of which being readily available implementations and being tamper-proof.