BundleID of an iOS Application installed on iOS 10.2.1

Figured it out.

Just navigate to
/var/mobile/applications for iOS versions less than 8.
/var/mobile/Containers/Bundle/Application for iOS versions less than 9.3.x and /var/containers/Bundle/Application for all versions greater than 9.3.x.
Find your application UUID (Universal Unique Identifier) and 'cd' into the folder.
Grep for the text softwareVersionBundleId in the file iTunesMetadata.plist.

Reference:
https://pspdfkit.com/guides/ios/current/faq/finding-the-app-bundle-id/


Managing and storing lots of SSH keys in the cloud

You have to make important distinctions: there are public keys and private keys. When "stored securely", they call for different notions of "securely".

Each SSH server owns a public/private key pair. Each server should generate its own key pair, and the private key should never leave the server itself. The public key is public, meaning that everybody can learn it. When you connect to the server, that's one of the first things that the server tells you: its public key. It shouts it all over the network. When dealing with SSH public keys and their storage, the question is really that of integrity: a given SSH client must remember the public keys of all the servers that it wants to talk to (the $HOME/.ssh/known_hosts file with usual Linux SSH clients); the attacker may want to include a fake public key in there, in order to run a fake server.

Each SSH client may own a public/private key pair: such a key pair will be used for client authentication by the server. If you use password-based client authentication, then the clients don't have such key pairs. If you use key-based client authentication, then each server must know the public keys of "authorized clients" (the $HOME/.ssh/authorized_keys for Linux SSH implementations).

In your case, you have 50 SSH clients talking to 4000 SSH servers. Therefore, using the normal SSH model, you would have to ensure that:

Each of the 50 clients knows a copy of the public keys for all 4000 servers.
If using key-based client authentication, each of the 4000 servers must know a copy of the 50 client public keys.

Given these figures, the relevant files will be bulky, and key management will be a problem (if you add a new client, the new client's public key must be imported into 4000 servers, with protected integrity). Public-Key Infrastructures were invented to solve that problem. A raw, "official" OpenSSH instance does not know how to use X.509 certificates; however, a modified version exists (see also that previous question). With an X.509-aware SSH code base, you could run your own Certification Authority (e.g. the open-source EJBCA), and issue certificates for your clients and servers. That way, SSH client and servers will send each other their certificates when needed, dynamically. Each machine will only have to store its own private key and certificate, and also "know" the CA certificate (in the relevant "trust store"). Adding a new client or a new server to the mix then is just issuing a certificate, and the management problem is solved (or, rather, moved around: now you have a PKI to handle).


IF what you ask was possible, THEN there would be no software or video piracy whatsoever. You could have some playing software that simply plays the movie but refuses to dump the data in a file, and that playing software would "prove" its unmodified status to the server, thus allowing the download.

This tells us that what you seek must be hard and would be worth an awful lot of money if it was ever invented. There also are good theoretical reasons why it is actually impossible, which would explain why nobody found such a way to reliably validate software remotely. The bottom-line is that you cannot ensure integrity of anything that runs on the attacker's own machine.

Now, if you have some high level of control on the target hardware, then things become possible. This is the security model of existing game consoles: the firmware and all games are under strict control of the publishers; no new software enters a console if it has not been digitally signed by an allowed publisher. Mere users cannot simply program their console. This is still hard to do properly -- console firmware, like any software, has bugs and thus all this signature-based shielding might be worked around occasionally -- but at least it can theoretically work.

But for a PC, forget it.


Issuing SSL certificates for device automation software package without domain names

I think there are two options here:

Server-side certificate - in this case you need to get one certificate on your server.  Hostname instead of IP address is a must and is very much preferable over the Internet and will save your customers a lot of hassle in the future.  There is an 'altSubject...' field in the certificate where an IP address can be entered and it will still validate.  Now, the client just need any SSL client and your cert issued by a CA trusted by the SSL client will work.
Client-side certificate - you can be the CA and issue your own certificates to all of your clients and as long as your Web server establishes the validity of the incoming client cert, it proves identity as well as confidentiality of transport.  Of course, these can be CA-issued as well.  This approach would be slightly preferable in your scenario as you would be able to revoke certs that don't pay for your software and still want to use it :)


Defeating identifying information that printers hide in printed documents

First of all, your premise that all tracking is done via micro-dots is incorrect. Recent developments show that tracking technology uses micro-shifts in pixels or other invisible steganography-like technology to include tracking information into print outputs. So smudging or backgrounds won't really be a 100% solution.

You've lined up most available options, I'd like to add a few more:

Option [1] Most cheap inkjet printers can't do it due to the vast tolerances in head movement and cheap electronics. Use a really cheap inkjet with a custom ink feeding system (to get down the cost of printing to an acceptable level).

Option [2] For the really paranoid - build your own printer, there are several projects that provide 3D print blueprints for ink-jet printers, and electronics + software are open source.

Option [3] My sources tell me that most manufacturers only build tracking technology only into their high-end models (enterprise use mainly, since the original fear was that powerful laser printers can print counterfeit currency), and for models sold in the US. Suggest buying a lower end color laser printer from markets that are known with more relaxed regulations (or privacy concerns), e.g. Northern Europe/Scandinavian countries. No guarantees obviously there (unlike the first two options, but you will overcome the severe limitations in the first two options).

Option [4] Go green! Save trees, print less or use e-paper (e.g. Sony DPT-RP1/B Digital Paper). I know, may seem like a stupid option, plus e-papers come with their own problems.

Option [5] Get your printers from Craigslist or second hand markets. Don't ever connect them to the Internet. Change them frequently via Craigslist or flea markets. That way it would be extremely difficult for someone to find out who/where/what, or connect the dots.

BTW the backgrounds you were referring to are here: https://drive.google.com/drive/u/0/folders/0B9ZrovajUPg2U3Z2Ul9WSXI0b1U

Other relevant reading (Steganographix, 2013--2014. Steganographix Documentation):
https://drive.google.com/drive/u/0/folders/0B9ZrovajUPg2NFEtNXZKUi02Tjg

Just my $0.02 :-)


Are hardware security keys (e.g ones supporting Fido2) "able to protect authentication" even in case of compromised hosts?

I understand that 2FA (MFA) increases account security in case an attacker obtains a password which might be possible via various ways, e.g. phishing, database breach, brute-force, etc..

Right. With 2FA you need a second factor to authenticate. For example, not only you give the passcode to the guard (something you know) but he also looks closely at your face to ensure that you are "Big X", and not "Spy Z".

However, if the 2FA device

I guess you refer to the common practice of using "something you have" as second factor.

is compromised (full system control)

Depending on the device, this could be quite hard, consider for instance a hardware token:

How would you go about compromising it?

which can also be the very same device then 2FA is broken. It's not as likely as opposed to only using a password but conceptually this is true.

If you compromised the second factor (e.g. the 2FA is in a smartphone app, and the smartphone is compromised) then the second factor is compromised. You still need to also compromise the first factor (phishing the credentials, compromising the computer from which the system is accessed...).
Or you may be referring to compromising a smartphone which has an app generating the OTP tokens and is used to access the remote system. Then yes, you didn't truly have a second factor, as it only needed compromising a single device.

Do hardware security keys protect against compromised devices? I read that the private key cannot be extracted from those devices.

Generally yes. The key is guarded by the hardware device. So if you use a compromised computer to do online banking, with a hardware security key as second factor, an attack wouldn't be able to log in as you later, since he would need the second password: to have the hardware device on his possession.
Please note that it wouldn't preclude the attacker to getting access to your bank page when you log in there. Also, there are multiple types of second factor hardware devices. While all of them require possessing the device itself (this may not completely hold if it's based on a software implementation, though), there are multiple ways of interaction:

Some of them require the user to take an action, such as providing the code showed on a
Some just need to be connected, and they get activated by the computer (sometimes after providing a password). In this case, a compromised computer might be able to get more codes than the user expected.
Others are commanded by the computer, yet they need physical interaction from the user for authorization, such as pressing a button or disconnecting and reconnecting the device. Some even have its own keyboard, so they can be feed a password without the (potentially compromised) computer learning about it

Do take into account the limitations of each approach. A compromised computer could ask you to confirm (via the hardware token) the action "Pay $50 bill to the utility company", yet what it is actually having you sign is "Transfer all the available money to the attacker's overseas account".
The hardware device confirms that the person holding the device the approved the action. However, it doesn't protect the integrity of the message the owner wanted to sign.
In some cases, where the device is not directly connected to the computer, it would even be possible to bypass the through a phishing page. The user provided the second factor bank token to log into the bank account, it just was not the bank web page (the extra effort is that they would need to perform the log in / actions exactly at that moment, as otherwise they would not have the temporary code).

I think about protecting my ssh logins with a FIDO2 key. Taking ssh as an example, I would imagine that on a compromised device the ssh handshake and key exchange can be intercepted and the Fido2 key can be used for malicious things.

The key can be used to sign messages. Just that. If your use f the key is to log in by ssh, it could be used to log in through ssh (which may require hardware confirmation, per above).

Additionally: Fido2 protects against phishing by storing the website it is setup to authenticate with.

More or less.

Does FIDO2 and openssh also additionally implement host key verification

I'm not aware of a specific security key using WebAuthnfor openssh, although I guess that could be done.
Also note that often keys support multiple standards. So you could have a key that supported FIDO 2 and also allowed ssh logins, but the later could be though an interface quite different than the one for FIDO.

or doesn't it matter because FIDO2 with openssh is already asymmetric encryption and thus not vulnerable to MitM attacks?

A ssh login through private key is not vulnerable to a MiTM sniffing the login credentials, since they are never sent on the wire. The user only shows possession of the private key. Which can be in a local file, or in a hardware device, it doesn't matter. It's out of reach of a network attack
However, if you don't do any host key verification, then the attacker could replace the machine you connect to, allow you access to their machine, and then get advantage of the actions you do on that one (like inputting passwords on that remote machine which is not the one you thought it was).


What is the relationship between "SHA-2" and "SHA-256"

Just to cite wikipedia: http://en.wikipedia.org/wiki/SHA-2:

  The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.

So yes, SHA-2 is a range of hash functions and includes SHA-256.


The Server: HTTP header is defined in the HTTP spec RFC 7231 section 7.4.2. I see nothing in there saying that you can't have multiple of these, so I assume this is spec-compliant; ie valid HTTP.
I agree with you that I'm not finding anything on Google for "SygiNet". I'm guessing it's some sort of proxy sitting in front of the web server, and it's adding its signature to the response. Whether that's useful to your pentest to know that there are some extra proxies in there, I have no idea ...


Can javascript code served by a server under HTTPS talk to another server under a subdomain with a different certificate?

Can a page served by (1) call (2) by javascript ?

Yes, using Cross-origin resource sharing (aka CORS).

Access-Control-Allow-Origin: https://adomain.com
Access-Control-Allow-Methods: GET, POST

  Can (1) and (2) "share" cookies ?

Yes, you can share cookies setting them to domain = ".adomain.com".


I would assume you understand what is going on here: when you try to visit a webpage, your browser is configured to use this AV as a "proxy." Instead of TRULY proxying the connection, the AV downloads the webpages (probably non-proxied) and opens them on a VM. It then (probably) checks for changes to the filesystem that could be interpreted as suspicious. For instance, modifications to system32 or Program Files (x86) (assuming you're on Windows) would be detected and the webpage would be blocked. Assuming no suspicious changes are found, (most likely in the virtual memory as well as the filesystem) the program fulfills its perceived role as a proxy and "forwards" the web page to you. The advantage of this is mainly that previously undiscovered viruses are still blocked, but disadvantages include poor performance. Also, a determined attacker wouldn't have too much trouble getting around this system (depending on how rigorous their algorithms for checking the VM are).

EDIT: To be a bit clearer, while there are undoubtedly some triggers installed on the guest OS, most of them are probably installed as part of the program and are separate from the OS entirely.


Possible Ransomware Infection, want to clarify some things

An adware popup came up and locked the browser.
  ...
  if the browser is locked and has to have the process ended does this
  indicate ransomware?

It could be a harmless bug in the JS engine etc.
If it is indeed malware, it's not necessarily ransomware, it could be anything.

...

Assuming it was malware:

  ran my av, nothing was detected

What the AV says or not says doesn't matter. Generally, AVs are pretty useless on already infected devices.

  however i plugged the usb drive back in to format.

After reinstallation? Not good. A different OS is a better choice for such tasks. ... Well, maybe (probably?) you got rid of it with reinstalling alone, but understand there is no 100% guarantee (even with different OS etc.)

  i am not sure if ransomeware can spread like a virus or a trojan

Ransomware can do everything normal malware can do, because it's just normal malware with some payment demand added. It could spread not at all, or over Mails, USB, Wifi, infect EFI etc.etc.

...

Ransomware often waits a long time without doing anything, before encrypting the files. If it is ransomware, what you should do now is to create a backup on a external disk and keep it. Ideally, you would have done this before a suspected infection, but's still useful. In case you really need it, however, don't just reinstall and plug the disk in to copy the files back.  A different OS etc. is very helpful, and take only the files you really need, ideally as little as possible.


How to crack SHA512 hexdigest passwords with John the Ripper?

From your description it is not clear how the salt and the hash are encoded into the hexdigest in your DB. First, you have to extract the salt and the hash from the digest. Than, you can create the sha512-crypt which is described at http://www.vidarholen.net/contents/blog/?p=33.


Well, let's use proper terminology then.

You don't want to encrypt passwords. You want to hash password. This is something completely different. Read this. There is a good password hashing function called "bcrypt" which is internally derived from an encryption algorithm called "Blowfish"; from which came a lot of confusion with some software platforms claim to do "password encryption with Blowfish", when they really mean "password hashing with bcrypt".

Now there is also an overload on the meaning of key. In cryptography, a "key" is a piece of secret data that is used as part of a cryptographic algorithm. Password hashing does not use any key (precisely because it is not encryption, despite the widespread terminology abuse). In databases, a "key" is some value that is used to reference a row in some table. This is not at all the same kind of key.

UUID are values which are meant to be unique (worldwide), but that does not mean that they cannot be guessed. Only that when you generate UUID "properly", then you will not get the same UUID value as any other person in the World who also generates UUID properly. Thus, UUID can be good for database keys (although worldwide uniqueness is some overkill), but not for encryption keys (but password hashing needs no key). UUID can be good for salts, a component of password hashing.


Why does the tool 'codesign' in OS X 10.11 (El Capitan) report every Python process as "code object is not signed at all"?

The executable located at /usr/bin/python does little more than spawn the application /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app. That application bundle doesn't have its own signature, but presumably it piggybacks on the signature of the parent binary.


The security of the PASSWORD function in MySQL

Surely that means that if my database is breached an infiltrator can easily create a rainbow table with a load of popular passwords and match the hashes.

That is correct.

The hashes don't differ from user to user. This means that an attacker can calculate a hash once and check it against the hashes of all the users. A salt would make this impossible.

In fact, the hashes don't differ at all, so an attacker could precompute a lot of hashes even before gaining access to your system.

Another problem is that the hash function used (2x SHA1) is very fast, and a brute-force attack can try many passwords in a short time. With commodity hardware it would be possible to try 3,000,000,000 passwords per second.

This password hashing method does not meet modern security standards.


Spend a little time browsing through the archives of a mailing list like Full Disclosure. You'll find real life examples of various kinds of web site attacks, e.g.:

SQL Injection in WikLink
PayPal Send Money Cross-Site Scripting Vulnerability

Or browse through the CVE database. Not every entry will have full details, but you can often find a link back to Full Disclosure or some similar site with the details you're looking for. (Or, in the case of open source products, you could take a look at the source to see what was patched.) Just a search on phpmyadmin will give you a rich set of examples which have the benefit of being open source and all coming from the same code base:

XSS
directory traversal
PHP code injection
failure to partition users?
installation information leakage
authentication bypass

It looks like there have been 17 advisories for phpmyadmin so far this year, so it's feasible that your staff could find a couple more if you assign this as a task during your training exercise.

Another category of helpful resources are wargames websites like hACME game and Hack This Site!.


Is Windows 10 [Password protection on wakeup] set to 'Required' relevant when machine is asleep?

It doesn't protect you from attacks over the internet (that's also not its intended purpose), unless you are using a VNC type of remote desktop solution. Ctrl-alt-del is more a protection from opportunists passing by your computer (physically).

Remote connectivity options like RDP always require valid credentials before a connection is established, even if the computer is unlocked on your side.


If you make a tcpdump of a nmap session, you will see that nmap sends a lot of packets, this patter is very easy to detect, and probably your session have been detected and then blocked automatically. Port scans are easy to detect by firewalls or other systems, that is my guess.


Are legal notices in a login banner legally significant in terms of computer misuse?

You should check out "Offensive Countermeasures: The Art of Active Defense" by John Strand / Paul Asadoorian.

There is an entire chapter early in the book that covers the importance of login banners, including case law.

These are a few of the examples included.

US vs. Heckenkamp (alternative write-up)
eHippie vs the World Trade Organization
Susan Clements-Jeffrey vs Absolute Software (forbes summary)


There are various easy to find solutions for dns tunnel so it does not make sense to describe specific solutions in detail.

But, this does not mean that these solutions will work with captive portals. These work only for captive portals which let DNS traffic pass and only redirect traffic to port 80 to the portal until the system was authorized. But there are other captive portals which instead reply to the DNS questions themselves in order to direct the user to the portal. These will not work with DNS tunnels.

Apart from that some tunnel solutions need TXT records to pass the data but some portals will only pass DNS questions for address records.


Calculating D-Wave's integer factorization capabilties

if you jump to ~10:00 in this presentation they actually appear to outline how they can perform integer factorization using quantum annealing and at ~12:10 they can produce a D-Wave machine (maybe as an NSA special order) that can factor 2n bit number with 2n^2 qubits.

First he describes that you can describe RSA as an optimization problem. But you can do that is a large class of problems, many of which are not believed to be efficiently computable on QCs. It should be straightforward to encode SAT problems like this, and those are NP complete. I'm also pretty sure that you can encode breaking symmetric crypto that way. The optimality results around Grover's algorithm make it unlikely that there is a generic algorithm that can efficiently solve all problems that can be encoded like this.

He does not mention any RSA/factoring specific insight. It's theoretically possible that the specific structure of factoring means that the optimization algorithm would solve the problem efficiently. But the talk did not contain any hint of evidence towards this. It's also lacking any evidence for a speedup beyond grover or even classic computing.


How the mobile operator knows whether I'm use phone, tablet or a computer for data service?

While I'm not sure of the exact answer to this question, I am aware that the user-agent string can be used by browsers to determine the type of device that the operating system is running on - often this is used in web design to dynamically display content based on what device is being used to view it.

To answer your question fully you must elaborate on when this 'tethering not allowed' message appears. Is it a prompt from your phones OS, or is it a message that appears on your internet browser when you tether it to your computer?

EDIT: To test this theory you could try using a browser plugin like Random Agent Spoofer for Firefox. If you manually set your user-agent to the same OS and browser as you use on your mobile device then it is possible that the service provider will be unable to distinguish between the traffic from your computers browser and data coming from your mobile device itself. However, this assumes that the provider or mobile device is not modifying the packets in some way to reflect that the packets are being sent from a tethered device. If this is the case then there really is very little that you can do about it.

From what you have described it sounds more like the the packets are being redirected based on the information inside the packet. For example any HTTP requests that are shown to be originating from the computer through the mobile phone are being redirected to a different source hence you are being served with a basic web page stating that you 'cannot use a tethered device'

As stated by other users, there are many ways that the service provider could potentially detect that you are using a desktop as opposed to a mobile device.


Is Privileged Access Management secured without regular Patch Update?

PAM solution system normally advice customer not to Patch their Operating System

This does not sound correct and I would suggest calling out the PAM vendor and looking into their competitors. I've never heard of a PAM vendor telling their customer they should avoid patching the OS. Sounds like a poor PAM vendor or a miscommunication


This will probably not work for a long time because there is nothing inherent in these "flaws" which cannot be reproduced by a machine.

The first problem you need to solve is to create an algorithm which produces such images which are easy to solve for most humans but hard to solve for current image recognition. Once you have this system in place to protect important sites it gets attractive enough to break it. And then it is only a question of time, i.e. the efforts to break the captcha are related to how much can be gained by breaking it.


You've got two choices:

Cut and run
Dig deeper

Option 1 involves physically unplugging the machine from the network, then treating it as hostile. It's been infected, therefore it's no longer your computer. Grab whatever files you need from it via a live CD, and wipe the drive. Make sure to run an up-to-date AV over the files you copy, just in case they've been infected with anything. This especially includes documents (.doc, .pdf, etc), as well as scripts and executables, as they're a common target these days.

Option 2 involves potentially losing data, and giving the attacker time to do nasty things with your computer / network. Grab a bunch of tools (Wireshark / Process Explorer) and work out what the hell is going on.

Some tips:

Store the Wireshark .pcap dump on a removable drive for later analysis.
Run netstat -an to get a full list of active TCP connections / listeners.
Launch Process Explorer, save the process list to a file, then dig around in anything that looks unusual.
Do a memory dump of potentially infected / malicious processes using ProcDump, with the following command: procdump -mp <pID> Save the dumps somewhere safe.
Shut down the machine, load it into a live CD, then manually analyse the registry and file system using forensics tools.

I highly recommend option 1 for safety, but the second option will provide you with a better idea of who the attacker is and what they're up to.


Can a hacker who has entered a virtual honeypot attack a LAN?

Using Does a Virtual Machine stop malware from doing harm? & Breaking out of the virtualization layer as a reference.

It could be possible. It would require a misconfigured VM network, shared access between the host and the VM or some other type of exploit to break out of the VM.


How do attackers find the IP addresses of recently deployed servers?

Your guess is likely correct.

The big server hosters have continuous IP ranges from which they assign IPs to their customers. Low budget hosters are frequently used by amateurs who don't know what they are doing, so it's likely that they use easy to guess passwords or set up insecure web applications. This makes these IP ranges valuable targets for black-hats.

When you notice such attacks from within the hosters network, you should report them to the hoster, because this is very likely a breach of the terms of use... or a server from another customers where the black-hats were already successful.


Professor wants a Wireshark capture of mail client and browser activity of my own machine

Now days, that capture should be mostly encrypted traffic unless he's also expecting you to do a MiTM (Man in The Middle).

Check your capture before turning it in just in case of surprises.

You could also set up a disposable email account to use just for this assignment.

The most likely teaching moment is probably the potentially large amount of ancillary traffic from advertisers and third party web sites that take place under the covers of going to a commercial web page.


How can I verify that network calls to my API come only from my C# program?

Every time this question came up, I point people to David Auerbach's Chat Wars: Microsoft vs. AOL. The story shows the extent that some very clever people have done to try to do what you're trying to do, and the spectacular failures one after another.

The article may have been written for a different time and technology stack, but the basic facts haven't changed and will never change, no matter what kind of technology you're using to develop your application. Given a sufficiently determined adversary, it is fundamentally impossible to verify that a network request come from your authorized client only.


Secure end-to-end when part of conversation must be over HTTP

Why can't it be changed?  You can use an HTTPS proxy where the user connects via SSL to the gateway adding the headers and then relays the communication on to your servers, also over SSL.  You can't have one SSL connection the entire way though, but that doesn't mean you can't have SSL connections for each step of the journey.

Otherwise, you are effectively asking an impossible question because you want to have a secure connection between you and the client, but want someone else to be able to be a man in the middle and modify what you are sending.  Those are mutually exclusive goals unless you make it so that the intended man in the middle can be in the middle of the communication.


Is it a good practice to forbid IP access to port 80?

I see some sites have blocked there port 80 (or 443) to be accessed by IP.

My guess is that you mean that access to http://hostname works while http://ip-adress/ does not work. At the TCP level the host is still accessed by IP address but the HTTP request looks different because the name given in the URL is contained in the HTTP request, e.g.

 GET /some-page HTTP/1.1
 Host: hostname

The main reason for having the hostname inside the HTTP request is that you often have multiple virtual servers with different hostnames on the same IP address. These have different configurations and the server needs to be able to distinguish which configuration should be used. If you give a hostname which does not have any special configuration then some default configuration is used and often this just displays an error page (what else should it do?).

And this exactly is what happens when you give an IP address instead of the hostname. Since there is no special configuration for Host: IP address the default configuration showing the error will be used.

Apart from that it makes sense to properly check the hostname even if their is only a single site on this IP address, because accepting an arbitrary hostname  can lead to DNS rebinding and similar attacks.


Security risk of allowing ICMP "destination unreachable" packets on AWS

"ICMPTX" is a very, very minor risk in most real-world situations.  It's basically a way for two cooperating programs to sneak data past a firewall that's only looking for data exfiltration over traditional protocols (TCP, UDP, etc.).  Unless your AWS VPC is infested with malware and your firewall is inspecting packets for attempted data exfiltration, I wouldn't worry about it.


For TLS 1.3, you are limited to a few pre-selected named groups (RFC 7919) and you include the identifier of the group with your key share. See sections of the RFC.
In previous versions of the protocol like TLS 1.2, the server sent the p and g together with the key share in ServerKeyExchange, again see the RFC. The server had to pick some values, either from Oakley group RFCs (RFC 3526) or a random value the server generated in advance using something like openssl dhparam 2048.
To the second part of your question, absolutely not and they have nothing to do with each other. The key exchange part performed by DHE or ECDHE and the authentication part performed by RSA or ECDSA (or theoretically EdDSA) do not share keys. Note how they often use different cryptographic primitives in the same handshake (most popular on the internet now is ECDHE with RSA certificates)!
The fact that the a and b in DH are called "private keys" and g^a mod p is called a "public key" is true, but a little confusing in the context of TLS. These are ephemeral, meaning single use, short term keys. They are the opposite of long term "identity" keys that you would use for authentication.
When you as a client connect to a server, the server has just created a new DHE key when you connected to it. Nobody has ever seen this key before, and when the handshake is over, it will be deleted. How would you use it for authentication? Who will you ask to confirm it?
Static-DH certificates used to exist (at least in theory) a long time ago. They don't exist anymore and are not allowed. They used long term DH keys for authentication and included the public key share in the certificate, but the certificate was signed by the CA using RSA. The key exchange performed ephemeral-static DH to confirm the server. This did not provide PFS and died out in favor of RSA key exchange (which also did not provide PFS) and then ECDHE+aRSA, which finally provided PFS.
Outside the context of TLS, protocols like those based on the Noise Protocol Framework, like WireGuard, use long term ECDH keys for authentication, together with different ephemeral ECDH keys used for key exchange, thus reusing code (less code to review). TLS doesn't do that because you need to confirm the validity of the certificate chain, and for that you need offline signature validation, which you can't do with Noise (as far as I understand, please someone correct me if I'm wrong).


To what extent can Google access data in the standard Android storage locations without restriction?

For legal issues regarding the data, you need to read the android terms of Use. There is probably a section on law enforcement.

as far as where the data is: On my google account one of the sync options is called "AppData".


Protecting against CSRF, JWT, cross domain

In general there isn't anything wrong with the authentication and anti-CSRF strategy outlined. Incorrectly implementing any part of it could, of course, expose risk but the strategy on its own seems fine.

There are a few areas of concern that are not ideal, the biggest one you already identified: supporting unencrypted use of HTTP. As you correctly pointed out, this exposes significant man-in-the-middle risk. In addition to the inherent risk for visitors or users choosing not to use SSL-encrypted communication, but also generally exposes greater risk for SSL-stripping attacks against users that intend to use SSL. Something you might consider here is making an SSL-only option available at the user (or user organization, if appropriate) level. Implementation details would depend on stack, but if you're using something like Express or Koa you could have a piece of middleware that validates that HTTP requests are allowed before returning a response. In cases where they aren't allowed you can respond with a 302 redirect to the HTTPS path.

The main advantages I can see for using a cookie versus local storage in this case are that:

The HTTPOnly flag mitigates risk of token theft via cross-site scripting (XSS). This certainly would not be the only concern if you have XSS flaws however, as successful exploitation could still issue requests from the compromised session.
If you determine whether the authentication is initially done over SSL (HTTPS), you can dynamically add the Secure flag to the cookie when you issue it so that SSL-stripping exposes somewhat less risk since the token would not included as long a the auth was secure in the first place. I would hesitate to call this infallible defense against SSL-stripping, but it's an easy way to add a little bit of defense in depth.
I may me missing a way as I must admit I've barely ever used the localstorage API, but I think you would need to scope localstorage to the whole domain, which means if anotherapp.mydomain.com (in keeping with your example) is vulnerable, it could compromise your localstorage containing your token. With the cookie, you can scope it to api.mydomain.com and use fairly restrictive CORS headers such as access-control-allow-origin: app.mydomain.com with access-control-allow-credentials as well.

It's not clear to me whether what you're putting in the iframes is intended to in some way interact with your content - something I would certainly caution against. In an ideal case, you would be able to stipulate that all embedded content have a valid SSL cert, and just use HTTPS throughout. Without that you are simply not going to have robust enough defenses to be reasonably confident against man-in-the-middle attacks.


Can global adversaries 'de-anonymize' any Tor user in a day?

TL;DR: correlation attacks are a possibility but there is always a gap between theory and practice. The other limitation is scalability.

An excerpt from that 2013 study shows that the technique is not that trivial:

  Our analysis shows that 80% of all types of users may be de-anonymized
  by a relatively moderate Tor-relay adversary within six months.  Our
  results also show that against a single AS adversary roughly 100% of
  users in some common locations are deanonymized within three months
  (95% in three months for a single IXP). Further, we find that an
  adversary controlling two ASes instead of one reduces the median time
  to the first client de-anonymization by an order of magnitude: from
  over three months to only 1 day for a typical web user; and from over
  three months to roughly one month for a BitTorrent user. This clearly
  shows the dramatic effect an adversary that controls multiple ASes can
  have on security

The other takeaway from the study is that you still need time, even a lot of time for uncertain results. The study does not suggest the ability of real-time deanonymization.

One thing we have learned in IT circles is that encryption in general is seldom defeated, but circumvented. People get caught because of opsec failures and lack of understanding of the tools they use.

Let's put the Tor network aside for a minute.

A browser has a huge attack surface. Even the Tor browser, which is configured with hardened settings is not immune to bugs or 0days. Javascript (which I understand is enabled by default in the Tor browser) gives away many small bits like the local time (which can be used to infer the timezone) and other bits of information that can be used for fingerprinting the browser or the user. The small bits add up and it is a start.

Now imagine an alphabet soup agency is after you, and they have some 0days in store, and they can weaponize a flaw in the Tor browser you are using. If they manage they take control of your computer, execute malicious code in the context of your user, or manage to leak your IP address you are done.

In this scenario Tor was not directly compromised. Sounds like something they could do or have done ? Probably.
There is an obvious limitation to this approach: a good 0day is expensive, therefore you cannot waste it against a low-value target because it is going to be noticed in the wild and ultimately fixed.

Bottom line: if you do something illegal or objectionable on Tor, you should be not using it from your home connection. Instead, you should borrow some public/restaurant/library connection and move from place to place. Preferably where cameras are rare. Most likely, this is the most effective defense against deanonymization attacks.

How do criminals using Tor get caught ?

From what we know it's not because of a weakness in Tor but because they did stupid things, like checking their personal Gmail account because they confused the Tor browser with their regular Firefox. All it takes is one mistake.

Or another stupid thing: lack of separation between their online and offline personae. Using a bitcoin wallet, funded with their regular bank account, making withdrawals to an account in their name (because they thought that BTC is "anonymous" and "untraceable").

Sounds so silly and yet this happens. Criminals get caught because they are dumb, careless and sometimes unlucky. It's not the because the police have magic powers.

Online crime is not just fought online but offline. Police resort to controlled purchases and classic infiltration techniques eg: buy stuff like weed, preferably from someone trusted in the community, a mod or someone high-up. Then trace the packages, figure out their shipping patterns, obtain camera footage. Identify the guy. Find the guy. Arrest the guy. Move up the chain. Get closer to the admins.

  I also don't get how dark markets and child porn still exists on onion
  sites if all it takes is a little bit of cooperation to de-anonymize
  everyone?

A couple reasons among many:

Many countries actually have established channels and cooperate on law enforcement issues, but not all countries are interested in cooperating with each other especially when they are adversaries
Many countries governments are corrupt to some degree, some engage in criminal activity for financial gain
Law enforcement agencies (LEA) do not have the time and resources to go after every offender, so they have to prioritize targets. When your darkmarket is regularly mentioned in the news, then assume it is already under investigation and possibly infiltrated. You have probably noticed that nearly every darkmarket ends up doing an exit scam and disappears. So you could say justice is already meted out without intervention from the authorities.
LEA take their time: rather than shut down an illegal operation outright they could watch the action and wait to catch more offenders. Consider for example the case of Hansa:
Operation Bayonet: Inside the Sting That Hijacked an Entire Dark Web Drug Market. Everything takes time.

The conclusion is that no system can be guaranteed to be foolproof but can nonetheless thwart the efforts of adversaries to unmask you. If you are a wanted person Tor should not be the sole security layer, but a component in your personal strategy and you still need good opsec. Tor does not protect against human mistakes and stupidity, this is beyond the scope of the project.


First: Do NOT use MD5. Ever. Never. Especially not in any form of security contexts. Use at least SHA-1 or SHA-2 (256 or 512/256 if speed is an issue on 64-bit machines). Apart from some legacy reasons, MD5 should be banned and the faster you stop using it the better you are off.

If you need a simple, pure Python RC4 implementation I have one at http://www.strombergson.com/files/rc4_gen.py.gz.

It is basically the same implementation we used as one of the sources for the test vectors in RFC 6229.

Yes, you should use nBytes. Look at the arcfour128, arcfour256 defined in RFC 4345 or some of the others we have calculated test vectors for.

I realise that I should move the RC4.py to GitHub. And change the fingerprint to using something other than MD5. Facepalm. ;-)


crypto/rand generates binary strings. Of course, binary strings cannot be used directly as plain text. You have to encode them into an appropriate text representation first (e.g. base64). Similar to your provided code you could use crypto/rand as follows:

import ("crypto/rand")

func rndString(n int) string {
    const alpha = "abcdefghijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789~!@#$%^&{}[]:,.*()_+-/?><."
    var bytes = make([]byte, n)
    rand.Read(bytes)
    for i := 0; i < n; i++ {
        bytes[i] = alpha[bytes[i] % byte(len(alpha))]
    }
    return string(bytes)
}

You should never seed the random number generator with the unix time. For any time an attacker could generate valid sessions very easily. If you are on a Linux system and if you really want to seed a PRNG you should read the seed from /dev/urandom which can be treated as a regular file on Linux systems.


Is it possible to use wildcard certificates on multiple devices?

The process you describe will work. Whether you will be able to enact it is a different thing: it depends on where, exactly, your private key is. In Windows systems, a private key might be marked as "non exportable", which means that Windows will not allow the export; the export is still possible (Windows is only software, it cannot do miracles) but somewhat hackish. On Linux systems, private keys are just files and files can be copied at will. If your private key generation and storage involved dedicated hardware then see the documentation of your HSM for possible options.

Possible objections against such a plan are the following:

There may be contractual issues. It really depends on the CA. The CA does not have technical power to prevent you from moving your private key from server to server (it is your key on your machines, they cannot spy on that), but they can still define it as a contract breach, at least theoretically. Commercial CA make money out of selling certificates, and you are buying and using a wildcard certificate precisely so that you do not have to buy a new certificate for each new server name; the commercial people at the commercial CA will understandably feel queasy at the concept, hence the possibility of some legal hindrance.
The value of a private key resides in its privacy. If your private key becomes known to outsiders, then you have a big problem. As a general rule, any export-transfer-import operation potentially exposes the private key; the more a private key travels, the less private it becomes. The "recommended way" is to have each server (physical machine) generate its own key pair, and never export the private key at all. What you suggests is at odds with this general principle, so beware.
If the private key is stolen, then the certificate will have to be revoked, and this will impact all your servers at the same time. With several distinct certificates, damage is more contained. Similarly, when the wildcard certificate expires, a renewal will have to be done, and the new certificates installed on all servers simultaneously. Depending on how many distinct servers you have, this may prove to be cumbersome.


I strongly suggest by starting in the right place, this is a Q&A site for Information Security, not a forum so I'm pretty sure this question will be closed soon. Answers cannot be opinion based, but I suggest you Hak5 on Youtube, SecurityTube, Pluralsight.com have the CompTIA Security+ and CEH path here and here, and get a bachelor on any computer science area to begin with.

And about the forum and Q&A site, if you want to have a discussion about what's better and what's not, and opinions try the Kali Linux Forums.


How many accounts should I have in an information system?

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

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

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


Warn on (plain, unencrypted) HTTP: in which prominent security talk was this advocated?

I think you might be referring to the video of Moxie Marlinspike's presentation at DEFCON 17, where he talks about his 'sslstrip' tool:

Video: More Tricks For Defeating SSL, Moxie Marlinspike, DEFCON 17, 2009-07-31  (starting from ~11:45).


Is there a multi-layered DoS protection which can be tightly integrated with cloud hosting services?

Provider's Responsibility

In the cloud, as a general rule, the cloud provider handles OSI layer 1 and 2 protection. This is essentially free, as they cannot offer a functional service without it.

At OSI layers 5+, it's generally up to you unless you're buying SaaS or PaaS. If you're buying SaaS/PaaS, it's likely the responsibility of your provider, although you'll need to check the SLAs to see what they actually guarantee.

Your Responsibility

From your question, it sounds like you are not considering SaaS/PaaS so layers 5+ will remain your responsibility.

You can pay CDPNs to take it off your plate. You could simply use the same tools in the cloud that you use elsewhere, although you have extra options in the cloud. E.g., you can spin up more servers automatically in response to a DDoS attack until you can figure out how to filter it properly.

The Tough Nut to Crack

The real issue is, as always, DDoS protection at layers 3 and 4. While you can mitigate or eliminate your DDoS risk at layers 5+, everyone is fundamentally very vulnerable at layers 3/4.

A competent attacker can saturate any customer network link; it is no longer shocking to see 10+ Gbps attacks. Major attacks have even threatened the internet backbone and root DNS servers.

This is why CloudFlare and their competitors exist. In order to address all potential attacks, you need several fast, independent routes and/or a responsive ISP. Large cloud providers can offer this directly, at whatever price they see fit, or you can setup third-party protection in front of your cloud environment.

Comprehensive protection against layer 3/4 DDoS attacks requires backbone-grade network links or cooperation from the companies that have them. Very few organizations can accept 10+ Gbps traffic and only pass through the bits that you need.

To be comparable to CloudFlare, you would need to look at AWS Shield Advanced, Azure DDoS Protection, or Google Cloud Armor. Amazon seems to offer the best free protection at the moment, but there are some gotchas in there.

Economics

When my company looked for DDoS protection, the CloudFlare crowd offered far better pricing than the cloud providers. The dedicated DDoS protection firms had the lowest ongoing costs and fairly low costs for intervention (where applicable). This may vary depending on your workload and threat model.

Your prices suggest a very small cloud presence. If you're looking to add protection to one or two small sites, Azure and AWS will be far more expensive than Google or CloudFlare.

I would tentatively suggest:

AWS if their free protection is adequate
CloudFlare or competitor if you can bend on external protection
Google Cloud Armor, Amazon WAF, or any other rule-based service may be within reach of your budget for small/light deployments (more than $5/month though)
Neither Azure nor AWS DDoS protection are within reach of your budget

Be sure to take note of services which charge based on traffic; the price will spike during an attack. There should be a discussion with the application owner to determine what costs they are willing to incur to remain online during an attack.


Trend Micro showing security warning on website. Unsure how to resolve it

Did you try to intercept any requests that were send to 3rd partys when clicking that button?

Check that websites for Crypto Mining scripts, or better: Open the websites manually and check if your antivirus has problems with it. I think clicking the button may send a quick request to a 3rd party that has these scripts somewhere.

If all of that doesn't work, mark it as a false positive.


How does webserver informs the browsers of the https capability?

In this case, it's a pretty simple series of HTTP redirections:

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://microsoft.com'
HTTP/1.1 301 Moved Permanently
Content-Length: 148
Content-Type: text/html; charset=UTF-8
Date: Tue, 24 Jan 2017 19:45:48 GMT
Location: http://www.microsoft.com/
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://www.microsoft.com'
HTTP/1.1 302 Moved Temporarily
Connection: keep-alive
Content-Length: 0
Date: Tue, 24 Jan 2017 19:45:56 GMT
Location: http://www.microsoft.com/en-us/
Server: AkamaiGHost
X-CCC: US
X-CID: 2

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://www.microsoft.com/en-us/'
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 0
Date: Tue, 24 Jan 2017 19:46:03 GMT
Location: https://www.microsoft.com/en-us/
Server: AkamaiGHost
Set-Cookie: akacd_OneRF=1493063163~rv=66~id=28df10e9d3a3627dfc38acff7feb884a; path=/; Expires=Mon, 24 Apr 2017 19:46:03 GMT
X-CCC: US
X-CID: 2

(I'm using httpie, a utility that's like an improved version of curl for cli usage.)

http://microsoft.com 301 redirects to http://www.microsoft.com, which 302 redirects to http://www.microsoft.com/en-us/, which 301 redirects to https://www.microsoft.com/en-us/.

In general, HTTP redirects are how many websites get users onto https.  Tools like sslstrip can sometimes foil these attempts, since the initial connection can be MitMed because it's not protected by TLS, which is why sites are increasingly starting to use HSTS headers, at which point the browser stores the information that the site should be accessed over https and sends the request there from the start (rather than assuming http when the protocol isn't given).


Why is whatsapp Inc. still caching user data even after introducing the end to end encryption?

All speculation wether what's app really uses e2e whenever possible (or if it's turned off with a kill switch whenever they like) aside:

If what the white paper describes is true, your data is fine in the blob, as it's encrypted reasonably well.

The only thing that would no longer work is data deduplication, e.g.

  If a file with that hash is already present, do not upload it, signal the user success.

This creates a heavier load on the servers - and possibly phone data plans for people copying Videos instead of sending links.

Note that if you were to upload a file a second time, your device might cache the file and the corresponding keys and send a reference to the same blob-object, sharing the same keys as before, to multiple other users.

This would somehow at least lower the amount of data that has to go on the server for a single person sending the same file to multiple people.


Guidelines for password register size in embedded devices

Remember that entropy is an attribute of a password, but it is not the password itself. You need a consistent way of transforming a password into that amount of entropy. Normally, this is done through a hash function, such as SHA256. (For a less secure system than bits on a chip, where the bits may be exposed through hacking such as a database on a web server, it's common to use a special purpose password hashing function, such as PBKDF2.)

SHA256, by definition, produces 256 bits of output. Obviously, you don't want to store 256 bits if you only need to store the entropy of a secure password. What you can do is estimate the capability of a credible attacker, and truncate the output to that.

To implement this, run the password through the hash algorithm, and save only the first n bits of the output. The properties of a modern hash algorithm include the property that a single bit of change in the input will produce a statistically random distribution of bits in the output. That means if I guess the password is AAAAAA, then guess AAAAAB, the outputs are completely unrelated.  All you have to do when the user enters their password is run it through the hash, and compare the first n bits to the stored bits. Collisions are precisely as unlikely as the number of bits you store.

Some people believe that 80 bits is enough to survive millennia of brute force attacks given current and near-future technology; this assumes no viable weakening attack is found on the algorithm. Other people believe that 128 bits is large enough to withstand any brute force attack. The banking industry trusts 3DES for credit card and PIN data, and that has 112 bits of entropy.  I'd decide the budget based on what others in the industry are doing.


How can I write logical signature for ClamAV simillar as it is in YARA?

Done. I was a little bit lazy to research deeper on my own, but here is an answer:

  Logical Expression

  This is where we will insert our boolean logic for detecting on our
  content matches. This uses operands like "&" for "and", "|" for "or",
  as well as "=", "<", ">".

So strings will be separated like:

(0|1|2);3c3f7068702024;68647337386870;6576616c

Simple as that.


Proxy Server advantage and public ip visible

The advantage of a proxy is not primarily that public IP are not visible on the internal LAN, but hat you have a better control of what the clients can do and what not. Just some examples to illustrate the advantage of explicit proxies:

User Centric Authentication and Logging

With an explicit proxy you can enforce proper authentication at the proxy, which means that you know which user is connecting. This way you can enforce user-specific policies, do user-specific logging etc. Without an explicit proxy you usually somehow associate the IP address of the client with a specific user which only works when each user has its own internal IP address (i.e. not with terminal servers or similar).

Independence from Target Ports

With a explicit proxy requests for all of  http://example.com/, http://example.com:8080 or http://example.com:8000 will be sent directly to the proxy and the proxy will connect to the given ports (80, 8080, 8000). Without such explicit proxy inspecting the traffic for malware etc is much harder. In effect you would need to have port independent filters like offered by some next generation firewalls. But these port independent filters are known to have problems, i.e. the firewall can often be tricked into assuming the wrong protocol and thus uses the wrong inspection.

Independence from Target IP Address

A common way to bypass "transparent" inspection is to send contradictory information. For instance if a firewall should block bad-site but should allow good-site one might try to set the Host header in the HTTP request to good-site but then connect to the IP address of bad-site. Lots of web servers don't check the host header at all and thus bad-site would serve the content even if the Host header does not match.

A typical transparent inspection looks only at the Host header and decide that the request can pass because according to the Host header the target is good-site. An explicit proxy instead gets the full URL, applies the policy to the URL and only if the policy allows access it continues with connecting to the given host, i.e. the target IP address is determined by the proxy and not the browser.

Better Separation between Internal and External Sites

If a browser is configured to do all requests through a proxy than the proxy could be used to separate internal and external sites. I.e. it could either deny access to internal sites or at least restrict cross-origin requests from external to internal sites and thus protect against typical Web 2.0 attacks from outside (CSRF, XSS, DNS rebinding...).


Was I hacked remotely, how could I find out? Windows 7

I would certainly format the computer but if you do not want to, and assuming you do not have a rootkit, you could:

-Use netstat to check active connections and see if there is something strange going on.

-If you are willing to, would be to proxy the traffic of your computer through another device and have wireshark or tcpdump capturing the traffic(a small raspberry pi?). Analyze it.Using a trusted external device would rule out the possibility of seeing tampered results.

-Check your running processes and startup ones. Check for those with high/intermittent cpu or high/intermittent network usage. When you are away from your pc, do as i do and disconnect the network cable. Check if the computer turns on even with the cable unplugged. This won't probably rule out anything if the malware connects to a malicious server but let us assume it is the opposite (the server connects to your pc and wakes it up).

-Paranoid mode: create a usb bootable kali and run some AVs and rootkit detectors on the hard drive. Running an AV on a compromised machine rarely works. You can also check the applications running on boot through the bootable distro. This also rules out the possibility of the OS misbehaving.

-As for the wireless, go to the admin page of the AP and disable wifi (to prevent a hacker who found your password from keeping the access). Change to WPA2-PSK and change the password (bigger is better). Through the interface check the connected devices: mac addresses and compare them against your list of devices. A malicious AP could also be ruled out by having you capture wireless/ethernet traffic from it to your devices to check if it is compromised and attempting to compromise the internal network.

Good luck and stay safe ;)


Is using enctype="multipart/form-data" always a bad idea?

Using enctype="multipart/form-data" creates both a binary and an ascii upload

I consider this statement wrong. There is application/x-www-form-urlencoded where the body of the POST request consists of the same string as would be used after ? in the URL if a GET request was used, i.e. like this:

  POST /foo HTTP/1.1
  Content-type: application/x-www-form-urlencoded
  Content-length: ...
  ...
  foo=one&bar=two

And then there is multipart/form-data which is a multipart MIME-message where each part consists of the key name given in the header and the body containing the value:

  POST /foo HTTP/1.1
  Content-type: multipart/form-data; boundary=abcde
  Content-length: ...
  ...
  --abcde
  Content-Disposition: form-data; name=foo

  one
  --abcde
  Content-Disposition: form-data; name=bar

  two
  --abcde--

Each part is only sent once and binary data (like file uploads) are sent only as binary.

  Apart from sending unnecessary data to the server, how this may be exploited?

Both ways can be used with several variations in order to try to bypass web application firewalls (WAF). With application/x-www-form-urlencoded one could for example try to play with URL encoding on unexpected places (like encoding the keys, = or &) in the hope that WAF and and server will interpret data differently. Or can could use duplicate keys etc.

With multipart/form-data one could try some of these variations too. But MIME gives even more possibilities, especially if a library gets used for parsing which gets also used for MIME in mails. In this case one could try to play around with innovative boundaries, duplicate boundaries (where server and WAF might pick a different one), try to use Content-Transfer-Encoding etc. But, a better WAF will simply discard any of these attempts since browsers will not issue such requests.


Yes, absolutely.  This is a classic man-in-the-middle attack.  All traffic (encrypted or not) runs through the server before being passed to you.  It would be trivial to read (and modify) unencrypted traffic (so anything over HTTP).

HTTPS is different.  As long as it's not a web based proxy, I think you'll be fine as long as you check the certificate is correct and valid for the site you're visiting. This is because to view your traffic, they would have to be able to unencrypt the traffic and then reencrypt it to you.  This means they would have to present you with a certificate signed for a domain they own and not signed for say, https://Google.com.


Does 2-Factor Authentication protect against malware?

2FA done properly helps protects your authentication to a system by making the login credential time limited. If you use a normal username/password and I obtain it, I can do bad things, as you, whenever I like. With 2FA I have maybe a minute or two to carry out my dastardly plans.

If you (or the service you're connecting to) has malware installed then you still have an issue. Part of your credentials may be obtained and combined with other weaknesses to do BadThings later, or it could be possible to establish a bridgehead on the target system to later exploit. Or maybe even go ahead and do something evil right there and then.

Saved credentials in the browser, remember me tick-boxes etc are by nature a reduction in security in return for greater convenience. If it's your login on your machine which nobody else uses and your anti-virus, patches etc are up to date then it's probably minimal risk. Also depends what the service is too - commenting on Stacks, El Reg  etc is very different to treasury operations for a Global100 corporation.


GnuPG - connecting to specific card reader when multiple reader available

You should put this instruction into $HOME/.gnupg/scdaemon.conf, not pass it directly to gpg.


File transfer secure from a network security perspective

From an L4 Firewall perspective, FTPS, HTTPS, and WebDAVS are indistinguishable from each other; SSH, SFTP, SCP, and RScync+SSH are also indistinguishable from each other. Additionally, from an L4 Firewall perspective, the TLS protocols are essentially the same as SSH based protocols, they're both tunneling protocol that can carry anything you put into them. In other words, yes, L4 Firewall is the wrong tool for the job.

What I would do if I were in your situation is to run a git server, over https, using Git SmartHttp/git-http-backend protocol. It ticks all the boxes:

Open protocol, open source implementation
It keeps history. You can choose to allow actual deletion, by allowing force push, or to disable force push and thus require explicit consent from both sides to actually delete from the commit history
Efficient transfer if most updates are diffable, and efficient enough even if the files are always completely different
Secured with TLS, and as it runs over HTTPS, and you can reverse proxy it with a webserver (e.g. Apache) if you want to. You can add any authentication you want that can be done over HTTPS using the webserver.
You can write a pre-receive or post-receive hooks to add any custom checking and additional behavior.

My second choices would be git over ssh, then rsync over ssh.

  for example making sure a SSH server is properly configured to only allow SFTP.

This may be easier than you think. There are a number of FTP server software that only supports SFTP without SSH shell support, so you'd reduce the chance of misconfiguring them.


Is there a reason why Android blocks emulating a RFID tag?

There are two different kinds of RFID tags.

Cheap ones which just broadcast their serial number in clear text as soon as they get into a magnetic field
Expensive ones which use a cryptographically secure protocol to authenticate

Cloning the first variant is trivial: You just record their number and broadcast the same one.

The second variant, however, is not that easy to clone. They have a secret key which never leaves the chip. You would need that secret key to clone them. So it's not like your Android device doesn't want to clone these tags, it can't.

Public transportation passes and access control cards are use-cases where cloning the card of someone else would break the system. Cloning the cheap variant is quite easy to do without the owner of the card noticing it. You just need to get a reading device close enough to their card. It is very likely that the makers opted for the more expensive variant to prevent people from cloning them.


Can you encrypt memory of server which hold luks keys?

There are some technologies that encrypt memory accesses in hardware, like AMD's Secure Memory Encryption (white paper, article on LWN), but it's mostly targeted against cold-boot attacks.

The general problem here is, that you'd need to save the encryption key somewhere to be able to use it, and then it can be stolen etc.
(The same LWN article describes Intel's "Software Guard Extensions", which seems a bit closer to what you'd like but has a hint of DRM smell on it, and apparently requires signatures from Intel...)

If you're running VMs on other people's machines, then you don't own and can't control the hardware, so not putting sensitive data (at least not sensitive keys) there is about the only option you have.


Confusion about the way password managers work

No communication is needed about "how to hash my master password correctly". That information is the same for every device and is defined by the password manager software which you run on your computer.

As for intercepting the hash, the most secure password managers would either use a "zero knowledge" system like Secure Remote Password (SRP) to prevent your password from ever leaving your computer in usable form (for example, 1Password uses this); or alternatively they might use a separate "account password" to log into the provider's server and retrieve the vault, with a different "master password" used to actually decrypt the vault.

Less secure password managers might actually send your master password, or some hash of it, to the server directly. This could in theory be intercepted as you fear, however any password manager with even a modicum of security will at least do the login over HTTPS or a similar encryption channel, which will prevent any such interception unless you or their servers are already compromised in some way, or unless they have made a mistake in the implementation which adds a vulnerability that can be exploited.


Yes, SSL is required, at the very least to transfer the "code" to the client, i.e. all of the HTML and JavaScript.  You could transfer the key using SSL when the client logs in, using a secure cookie, and then have the client-side JavaScript code make non-SSL HTTP requests using the key contained in that secure cookie.  However, this adds a lot of complexity, and SSL would be simpler, less error-prone, and probably faster anyway since cryptography in JavaScript is likely to be slower than the SSL implementation in the web browser and web server.  Furthermore, unless the data is extremely non-sensitive, you should encrypt the requests and responses, in which case SSL would be needed anyway (there would be no benefit in trying to do the encryption in JavaScript).


If you are really worried that there may be some malware on a removable device than your best bet is probably to run a live linux disk to check the device.  This will give you the ability to access / scan any devices without putting your local hard disk at risk.


The short answer is that it takes a loooooong time for software to die. Even in 2018 we still have COBOL running multi-billion dollar companies, despite COBOL being a "dead" language for decades.

The longer answer is there's still a significant amount of websites that require Flash, and people re-enable Flash for practical reasons.

Oftentimes these are "mission critical" internal corporate websites or schools that haven't put a priority on replacing legacy applications based on Flash.  This might mean using older browsers where Flash isn't disabled, or just users being trained to re-enabled it every time.

Across the board, the numbers as of April 2018 are around 5% of websites according to https://w3techs.com/technologies/details/cp-flash/all/all

So I wouldn't say Flash is "dead", but it is slowly dying.


Wifi hacking has more scene. So maybe this is because your client thinks is safer... but it is not. Anything can be hacked if you don't take the appropiate security measures. Both of them can be victim of DoS too.

Advantages of using wifi

Higher range, so if the factory is large, less hardware will be needed to cover all, son less money I guess.
More compatible hardware.

Advantages of using bluetooth

I don't know! maybe they are less people focused on bluetooth hacking, so less tools.

Anyway, I think (personal opinion) A wifi network can be a good idea if you do well the configuration. Some standard security advices:

Disable WPS
Use WPA2 AES encryption, is the strongest of the standard available for now.
Use certificates or if not possible, use very long non-existing in dictionaries passwords using lowercase, uppercase, symbols and numbers.
Use if possible Radius instead of PSK (if possible).
Use "clients isolation" if possible. Only if not needed to connect from clients to clients.
Your wifi network should be in a different network subrange with port filtering to assure only accessing to the minimum required services.
If your money is ok, use hardware WIPS (wireless intrustion prevention systems) to try to prevent DoS. This is not usual, is not cheap.

With that standard security measures, you have a good wireless networks. Anyway, always everything can be hacked, you know :)

EDIT
Regarding the key exchange on wireless networks and on bluetooth...

Bluetooth security is limited to key matching. In wireless networks the security standards have been raised with inclusion of new versions from the old-easy-to-hack WEP until complex key exchanges or certificate validation like on EAP-TLS.

Some other opinions supporting this on this article.

So finally my opinion too is Wireless is more secure, or at least, has more security mechanisms.


Ransomware encrypted first 64 kB of file

Not really. If the files had a very large common header (64kb or more), you might be in luck, else you're essentially trying to guess 64,000 "characters". Assuming the file used only 64 characters (e.g. it was a Base64 encoded file), for example purposes, that would be 64^64000 possibilities. That's a number with over 100,000 digits in.

Given that guessing a 12 character long password is considered "hard", and that only has 64^12 (4,722,366,482,869,645,213,696 - only 22 digits!) possibilities, you can see the issue. Guessing a 64kb "string" is over 4500 times harder, and that's ignoring that files aren't restricted to 64 characters in reality.

In practice, a lot of file types wouldn't require all the bytes to be guessed, but most file headers are much smaller than 64kb, so there will be quite a lot of unknown data even so.


Verifying Encryption at Rest with Oracle 11g

If you can look at the database, you can look at the actual tables and see that the data is stored in an encrypted format, or if its' stored in plaintext. You can also check that the entire database is/is not stored as an encrypted object.

If you have access to the source code for the software serving the database info you can check the logic in the function and see if it encrypts/decrypts data as it is entered into the database or removed.

If you have access to the server as a whole you can check that disk encryption is in use.

If you have access to nothing your easiest way to check is to see if the software used is listed as being compliant with HIPAA/PCI regulations, and see what their website or your systems' administrator can confirm to you.

At the end of the day without knowing what software serves you the SQL tables, and without having access to view the SQL tables, it's kind of an open-ended question that is probably best resolved socially rather than technologically - ask someone who knows.


What's the security concern of browsers using the HTTP CONNECT method?

The CONNECT method leaves the TCP connection at a different state than it originally was; unlike other HTTP request, the CONNECT method is stateful, it is always the last HTTP request that can happen on that TCP connection.

Once the CONNECT request is finished, that connection cannot be used to transfer other XMLHttpRequest, and instead are solely usable for the tunneled protocol. So the browser would have to discard the connection once the tunnel is closed.

Back when XMLHttpRequest was originally written, Javascript didn't have a Socket API (and it still doesn't now; despite the name, Websocket isn't really a true Socket API, it's more like Messaging API because it has automatic message framing and cannot be used to write arbitrary bytes to the underlying socket), so there isn't really a way to use that tunneled connection from Javascript.

Since the browser can no longer use that TCP connection for anything, and since JavaScript cannot use that connection either due to lack of Socket API and a way to reference the connection, the only valid thing that the browser can do after a CONNECT request is to close the connection.

Prohibiting CONNECT limits the scope of XMLHttpRequest API so standard authors and implementers doesn't have to deal with those issues, and XMLHttpRequest can be designed so it only need to deal with stateless requests.


How does SSD with SED encrypt and decrypt data?

The encryption process takes place in the embedded processor on the SSD.  Consequently, it's in the computer's RAM and the SATA (or PCIe) bus in plaintext, then copied to RAM on the SSD, encrypted, and written out to a flash block.  The unencrypted plaintext should never hit the flash of the SSD.


Best strategy to recover running Macbook "modern" Pro ram

The best strategy depends on what your constraints and goals are. A quick answer...

Perhaps an alternative is to powerbutton-off the laptop and then bootup a USB Linux which does not "touch" the RAM

All bootable systems will touch memory. Lighter systems touch less, but still some. However, the memory will be scrambled with a (weak) LFSR algorithm, so the memory you read will need to be broken using cryptanalysis. It is possible, but it's not as simple as running strings on the dump.

does the very act of power disconnection affect the RAM contents?

The act of resetting the system will typically cause the LFSR scrambling seed to change. The BIOS may also wipe some (or all) memory. In that way, the act of turning on power changes memory contents, even if the act of cutting power does not. Additionally, every instant that power source is disconnected from the memory modules, more data is lost. The time without power must be minimal.
Software
This is a common technique where a privileged program is made to read all memory on the system. It is typically fast and does not risk hardware damage or loss of all data, but it can "taint" the memory with its own presence. Additionally, as it is capturing memory from a running system, there can be a bit of memory smear. This is an issue with two distant physical addresses that correspond to a contiguous region of memory. When accessing the memory is not atomic, you can have a snapshot of data from different points in time. The earlier addresses will be from an earlier point in time than the later addresses. There is an excellent paper  explaining this issue and the various workarounds for different types of memory acquisition.
The Volatility framework has many plugins for live analysis of memory on a system. It can, for example, dump arbitrary process memory for subsequent analysis. Unlike most other "raw" memory acquisition techniques, Volatility works with the system to maximize the relevance of memory dumps. However it is also quite invasive and uses a lot of memory. This is only an issue if the memory you want to retrieve is present in unallocated memory.
Direct Memory Access
When a PCI/PCIe device has been configured by a driver to become bus master, it will be able to initiate DMA reads and writes to arbitrary locations in memory. The speed of data acquisition then depends entirely on the transfer rate of the device. Common devices used are Firewire, Thunderbolt, and CardBus, which all have DMA capabilities. Custom PCIe devices can be hotplugged which also read memory contents. PCIe natively supports hotplugging, whereas legacy PCI may be damaged by live hotplugging. This technique has the benefit of not tainting memory with any software, but it has the same downside as the above method where atomicity is not guaranteed.
While not technically considered DMA, another way to gather memory from a running system is the IEEE 1149.1 debugging protocol, called JTAG. This involves a hardware probe being attached to a specific header on the motherboard. A signal is sent to the CPU that puts it into probe mode, turning it into a puppet. The CPU can be halted and memory read, making this technique capable of obtaining an atomic snapshot of memory. The downsides are that not all motherboards support JTAG, probe hardware can be quite expensive on older systems, and reading memory over a debugging interface is very slow.
Cold boot attack (reboot into a live system)
For this kind of cold boot attack, the system is rebooted into a system with a small memory footprint that reads the memory. This works because a reboot does not actually power down memory, leaving the previous contents intact. The downside is that the software you boot into will still need to eat up a small amount of memory. The laziest technique with the biggest footprint would be a live Linux OS. A slightly more complex technique that has a smaller footprint would be a custom bootloader. Finally, you can even write a custom BIOS that reads the contents of memory and exports it to another system, e.g. over a serial bus.
Unlike the above two options, this provides atomicity. As soon as power to the DRAM is cut (whether due to the actual memory modules being removed, or the system being rebooted), the entire contents of memory are frozen in time, providing a perfect snapshot. This can provide legally effective evidence, as you do not have to prove that your acquisition technique did not modify memory. There is a downside to this technique though. As it involves hardware, there is a greater chance of the contents of memory being destroyed. If you make a mistake, you can't go back and try again. Another issue is with the behavior of the BIOS. During the POST test, memory may be wiped for automated pre-boot testing. ECC memory is actually required to be wiped by the BIOS and put in a consistent state. Some of this behavior is described here, specifically in the context of the behavior being abused to mitigate cold boot attacks.
Cold boot attack (memory transfer)
A cold boot attack of this type exploits the memory remanence property of modern DRAM. To store a single bit of data, DRAM charges a capacitor. Every 64ms, the memory controller will check the contents of the capacitor and refresh it if necessary. To read a bit, the voltage of the capacitor is read. While, for reliability, they need to be refreshed every 64ms due to heavy leakage (they are very small capacitors), they can still often be read even seconds from the last refresh. This allows a system to be turned off and still retain memory for a split second. Exploiting this requires physically removing memory from the system (ideally after blasting it with ice-cold coolant to slow the memory decay) and transferring it to a system you control. This has no memory footprint as no programs must be stored on the modules, but it does carry with it a greater risk of memory loss. Every instant the memory is powered off, the chances that the capacitors fully leak their charge increases.
Applicable to both cold boot attack techniques, modern memory (DDR3 and DDR4) uses a technique called memory scrambling to reduce electrical interference caused by successive bursts of 1s or 0s which could overload the controller. Memory scrambling utilizes an encryption algorithm called LFSR. However, this algorithm is highly vulnerable to a number of cryptoanalytic techniques. You must keep in mind that a cold boot attack will likely require that you break the LFSR.
I wrote more about cold boot attack techniques in a question from a previous account.


The match threshold is specific to both the type of biometric and the individual implementation. In academic terminology, the match threshold is generally measured as a percentage of features matched, although each feature does not necessarily contribute an equal value, nor does each feature necessarily contribute to a single global score. It is fairly common to find that biometric systems produce several different properties during comparison, each with their own separate algorithm and threshold. Common units for scores are a percentage, a ratio of matched to unmatched features, or a dimensionless number.

As an example, fingerprints have three main characteristic patterns: arches, loops, and whorls. One can trace each ridge on the print sample, vectorise it, and categorise it as part of one of the three pattern types. While absolute locations are generally not useful, the inter-ridge distances and relative positions of features (e.g. the peak of an arch or the extents of a whorl) are much more reliable for comparison. In a single fingerprint, one can match the presence of features, the weighted average inter-ridge distances across the sample, and the extents of the features. Each of these scores is produced by its own algorithm to perform the comparison, which outputs its own convenient type of result (e.g. a percentage), and is generally configured with an individual threshold based on the accuracy and security requirements of the system.

Threshold values are generally developed through trial and error, influenced by statistics such as False Acceptance Rate (FAR) and False Rejection Rate (FRR). You can read more about computing FAR and FFR here.


Which RFCs should I read for web pentesting?

Pentesting isn't about knowing RFCs by heart. If there is a specific information you need for a specific test, you can always just look it up.

It's much better to have broad fundamental knowledge, and know where to find specifics, rather than to attempt to cram as much specific knowledge into your head as you can.

The question "Which books should I read when starting Pentesting?" is very opinion-based, and will not be answered, as those answers would be outdated very quickly. One resource that comes up often is the OWASP Top 10, as those are vulnerabilities that come up very often, and understanding those will help you quite a bit.

Don't be afraid of asking well-formulated questions regarding your understanding of specific topic, even if they are not attached to a real-world problem.


What security layers of protection are available over XMPP?

The core XMPP specification defines how it integrates with TLS for transport security, and SASL for authentication.

There is also a standard end-to-end signing and encryption protocol that can be used to ensure protection of messages from sender to ultimate recipient, whereas TLS only protects up to the next relay host. This end-to-end protocol builds on S/MIME.

Also, depending on the context, you may have the option to put clients and servers in their own VPN, which will protect the traffic against outsiders. This is generic to every networked application and is done at the OS level.


What are the reasons behind Oracle password restrictions?

I would say that other character might confuse Oracle parser.
You use SQL change the password:

alter user xxx identified by pass;

There are NO quotes around the password. So I would say it is for legacy reasons.
Oracle has same restrictions also for identifier/table/column names.

PS: password strength (entropy) is not primary determined by possible chars, but by it's length. In case of the password it's the length what matters.


Internal / external Penetration testing a webserver - PCI

I deleted my previous answer because I decided that it required too much overhaul.

Internal penetration testing happens within your organization to test how vulnerable you are to an inside threat. External penetration testing is done from outside the organization to test how vulnerable you are to an outside threat. In both cases, a penetration tester probes for vulnerabilities and reports on the findings. Yes there is software for this, but the software is a tool for a professional, it does not replace one.

When you host a web server and/or database with a 3rd party, the game changes. External testing can be performed that also includes application vulnerability testing (which is what my previous answer focused on). But internal testing now becomes a challenge. Some hosting companies that specialize in hosting PCI-compliant servers will perform the testing themselves and report to you on the results. If you are storing credit card details on a server hosted by a third party, you might be non-compliant if you don't have a dedicated server. Check with your hosting company to see if they handle PCI compliance.

The short answer is:

penetration testing is done by a professional
you need to work with your hosting company to get and remain compliant


The comments have a good point regarding endpoint security of your threat model:

If you do not trust your endpoint to store the data, you shouldn’t trust it enough to input your data from a piece of paper.

Not trusting password managers is strange as well - did you do a full analysis yourself on veracrypt, which you seem to have trust in?

I‘m not advocating for dumping encryption technology at large, but a password manager is probably the easier-to-review code base when trust issues go that far.

Other than that, here are my tips for keeping good passwords - and you should do that regardless of the grouping you did (as it is only little overhead for not-as-important passwords)

Use a password manager that you trust.
Use a machine you trust.
Use a multi-factor authentication where possible (i.e. a U2F-token like a yubikey or at least a software based Token generator).
Do not reuse passwords.

There is another problem your threat model is not addressing which is availability: loosing those passwords will probably be bad. Thus, it is a good idea to keep the database you created on a second device. For example, you could export it with a PGP key encryption on a thumb drive you carry with you at all times and keep the key for that on a yubikey in a bank safe.

This way, you should be able to recover the keys and you can create new backups without needing access to the yubikey.


Is it possible to determine if the BIOS has been modified between two points in time?

If your board is compatible you should be able to use flashrom with the -r arg to backup the bios to a file. You can then use md5, sha256, etc to grab a hash which can later be compared.

//baseline.sh
//first make your baseline bios checksum with
flashrom -r ./bios.bios
sha256sum bios.bios > bios.checksum

//check.sh
//now periodically check again
flashrom -r ./bios.bios
sha256sum bios.checksum -c
//if your output looks like "bios.bios: FAILED" you have a problem.


I've now written my own nmap scan parser. Unfortunately the tools listed in the answers, and the tools Ive tried have not been what I've needed. I also been using some nmap script output aswell which needs to be stored in a way to allow easy aggregating of data. I found that writing my own script was easy enough to deal with my situation.

Thank you for answers!

UPDATE: Source code can be found here . Anyone wanting to participate can send me their email, and I'll add you.


XSS inside JavaScript string literal without single quotes?

That's not XSSable.

(I'm assuming in your scenario angle brackets are blacklisted too. Otherwise, you could obviously close the script tag with </script> and inject a separate script that doesn't use single quotes.)

In JS/ES syntax, a string literal that starts with a single quote needs to be ended with a single quote. Since you can't inject one yourself, you may at most cause a syntax error by introducing unescaped line breaks or escaping the closing single quote with a \. An attacker could use that to prevent execution of the current script which may eventually be chained with other bugs to something more severe. But it's not XSS-exploitable by itself.


Identify the attestation certificate (X.509) in Fido U2F registration response

The U2F Raw Message Formats document specifies that the attestation certification is encoded using the Distinguished Encoding Rules (DER). The DER are Tag-Length-Value (TLV) style binary encoding. Thus, you only have to read the first DER unit - and only the TL part of it (i.e. just a few bytes). Decoding the TL part of it gives you the remaining length of the certificate.


How to safely exchange functionality of a file between two computers?

Question is strange, but here is an alternative approach. Sure you can keep your machine clean 100% of the time. Create a virtualized hardened host, take a snapshot, do your work, send your work, close virtualized host. Never use the host for ANYONE, not even connecting to the Internet, you could save your work on a USB send it from another machine. When you go back to do your work, revert the snapshot problem solved.

From a realistic perspective though, Steffen already laid out the risk based approach. If you cannot trust your own network, surfing habits, then you have more to worry about. In a sanitized environment (as mentioned above) there is no mechanism to introduce any risk if the virtualized host is never networked. You could go as far as mounting a shared folder to transfer data to a networked machine, but then you're back to square one train of thought: "then I am networked and vulnerable." From a virtualized/non-networked machine, I fail to see how anything could be introduced without any iota of networking (ethernet, wireless, bluetooth, etc)


What can I do with blind SQLi if the database is encrypted?

You already cracked half their defenses. Now all that's left is a compromise of the AES key. That should be a reason to worry. Especially because changing that key won't be trivial, because they would have to re-encrypt the whole database to do that.
Symmetric encryption with a static key on cell level means that duplicate values stay duplicate values. This can give you a hint about the content of some fields. For example, if you know that a certain database row has the value "HIV positive" in a specific field, you can now identify all other rows which also have that value.
When you have a blind SQL injection, you might be able to destroy data using UPDATE or DELETE. You can also INSERT data, but without the encryption key you can only insert gibberish. This might still cause trouble, though.
You said you can get the stored procedures. Those might do something useful even without having to encrypt or decrypt anything.


Openssl adding a telephone number or cell number to the distinguished_name

telephoneNumber is what you're looking for.

Add the following to openssl.cnf; I used the Ubuntu 14 system version to start with, section names may vary by your distribution:

Under policy_match and policy_anything sections (probably policy_* in whatever openssl.cnf you're using as a template):

telephoneNumber         = optional

Under req_distinguished_name section:

telephoneNumber                 = Telephone Number
telephoneNumber_min             = 11
telephoneNumber_max             = 40

Then generate a key and CSR as normal.  The interactive prompts will now include a telephone number:

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Massachusetts
Locality Name (eg, city) []:Boston
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:root@example.com
Telephone Number []:617-555-1234

And you can verify that the telephone number makes it into the cert:

$ openssl x509 -in certificate.crt -text -noout | grep Subject:
Subject: C=US, ST=Massachusetts, L=Boston, O=Internet Widgits Pty Ltd, CN=www.example.com/emailAddress=root@example.com/telephoneNumber=617-555-1234
$

Some references as to how I figured this out:

RFC 5280 says that

  Standard sets of attributes have been defined in the X.500 series of
  specifications [X.520].

A bit of Googling led me to Naming and Structuring Guidelines for X.500 (RFC 1617) which has section "4.4.7 Telecom Attributes".  There's not much info there but it does state telephoneNumber.  So I Googled for that along with openssl.cnf and found an example openssl.cnf file incorporating telephoneNumber.  From there it was simple to test the necessary parameters on my own system.

Finally, knowing that telephoneNumber is a valid thing, it was possible to Google "site:openssl.org telephoneNumber" and the source code for obj_mac.h has that along with facsimileTelephoneNumber, homeTelephoneNumber, mobileTelephoneNumber, and pagerTelephoneNumber.  (Personally, I think if you're just putting one number in, you should be general ("telephoneNumber") rather than pedantic ("mobileTelephoneNumber"), so that's what I've used above).


Broken into my office, HDD/SSD stolen. How secure is Chrome password saving feature?

Change all passwords now

Most online password stores are all pretty secure at protecting the data over the wire and while it is sitting in the server center ... but if it is sitting in your browser on your physical device it is mediocre at best and terrible at worst.

If chrome starts up with out prompting for your password ... you're toast!  They have them all in plain text.
If chrome requires a login, I believe the passwords are still encrypted and stored on the local computer ... which means they can decrypt them (different than cracking a hash).

Either way, your best bet is to change all your passwords RIGHT NOW.  I would start with the high value ones like Email, Bank, Stocks, and then work towards things that have access to your payment creds like online stores, and then social media which might seem like the most important but is less likely to crush you long term.