Critical sub-packets in OpenPGP not used

The Critical Bit

  OpenPGP in RFC4880 allow to tag signature sub packets as "critical" by setting the high bit 7 in the packet type. I checked a few keys generated with GnuPG2 and all the sub packets are not critical, even for things like "9 - key expiration time".

OpenPGP, RFC 4880, 5.2.3.1.  Signature Subpacket Specification defines the critical bit. It can be set to inform older implementations of OpenPGP that if they do not understand a subpacket, they should consider the whole signature as invalid.

  Bit 7 of the subpacket type is the "critical" bit.  If set, it
     denotes that the subpacket is one that is critical for the evaluator
     of the signature to recognize.  If a subpacket is encountered that is
     marked critical but is unknown to the evaluating software, the
     evaluator SHOULD consider the signature to be in error.

So if a new release of OpenPGP defines new kinds of signatures, and a signature is restricted in some way that older implementations will not understand, you could have the newer OpenPGP implementation have the critical bit set to denote "If you don't understand the signature subpacket, consider the whole signature as invalid".

As all those subpackets have been defined at the same time the critical bit was defined, fully-fledged implementations should support those anyway.

  Is there an agreement to not use critical for well known (i.e. specified in the RFC) packets?

The RFCs relevant for OpenPGP (especially 4880) do not mention details on when not to use it.

Setting the Critical Bit in GnuPG

  Can I control which packet is marked critical when using GnuPG CLI to create a key signature?

man gpg2 shows up some use cases, in which you can set the critical bit for notations and key server/policy URIs by prefixing !:

  --sig-keyserver-url string

  Use string as a preferred keyserver URL for data signatures. If you prefix it with an exclamation mark (!), the keyserver URL packet will be flagged as critical.

Interoperability

  Are the interoperability issues expected?

Well, the critical bit is meant to prevent "broken" interoperability, when an older implementation does not implement important new features. So to some extent, it prevents operability, but at the same time this is why it was set after all.


Whats the point of publishing Gmail password lists?

First of all, I'm not sure lists of Gmail account details are published daily. As far as I know, Gmail has not been a major data breach (but subsets of data could of course come from other sources).

But why is the data useful? Some reasons:

Gmail try to catch suspicious looking login attempts. I think this is mainly done by looking at the geolocation of the IP and the HTTP user agent header. But what if the attacker uses a VPN ending up in an area near where you live, and the same browser as you do? (Plus, I am not sure Gmail always blocks logins - sometimes it just notifies you of the unusual attempt but still allows it. I am not sure what policy they have.)
Even if you can not use the passwords on Gmail, accounts might be created with the same details on other sites with less strict security. Accession those could be of value for an attacker.
As shroeder says in comments: "Bragging rights to say that they were successful in breaching the target systems and company." (I don't think this is the most importnat motivator, but it is one.)

The bottom line is that you should not rely on Gmails heuristics to keep your account safe. If your password is leaked, that is bad and you should change it on all places you use it.


Should binary signature checked before launching from trusted locations?

It depends on your goal, and the sensitivity and other defenses of the system.

If your intention is a defense-in-depth measure, either against an incompetent/compromised/malicious admin or somebody using an exploit on the system, then checking signatures makes sense. It's not a perfect protection, because of course whatever code performs that check could itself end up compromised, or an attacker who is aware (or paranoid) of the risk may bypass the signature check by tampering with code in memory or performing a similar trick. For that matter, sufficiently well-funded malware may even manage to get itself signed by a trusted but fraudulent certificate (it's happened before). Defense-in-depth measures very similar to this have saved companies from attackers before, either catching them red-handed or at least stymying them enough that they couldn't reach the real goods before their intrusion was detected and their access cut off.

On the other hand, if the system is already very well-hardened and has good perimeter security, plus nobody who logs into it as Admin except a few trusted individuals for very rare, specific, and monitored operations... well, if you've got that level of security already you probably care enough to go for the additional defense in depth anyhow, but it's less likely that you'll need it. Alternatively, if the system isn't that sensitive (say, it's some user's home computer, unlikely to be especially targeted and not holding any amazingly valuable secrets), it may simply not be worth the engineering effort to set up and perform those checks. It's also worth testing for a performance hit; verifying a signature (especially on larger files) takes some time, and may prove unacceptable.


In the light of recent information about RarVM, can we still trust RAR files?

Note that in this case, what is deemed insecure is the RarVM implementation found in WinRAR, and probably not in the core design of the VM (if so, more interesting).

So you can either assume WinRar itself is insecure (something not improbable) or that all RAR files are insecure (more improbable than before).

What you do with this information, is probably nothing. You can decide you only accept ZIP files, but you're going to have trouble implementing that.


Why do inflight wifi networks display a captcha?

I suspect this is to prevent inadvertient activation of service.

Imagine you have bougt a one-hour pass to use at a later time. When you start up your computer, your computer might try to update its antivirus, or may try to download some windows updates, thus prematurely starting your one-hour pass when you dont want.

Thus, they have a captcha to activate a pass (regardless of its a pre-purchased pass in your account or a pass that you purchase on the spot) just so you don't inadvertly activate the pass without your consent.

For example, look at these roaming "accidents", where a phone in the background, decides to download a software update or whatever, causing bills long above € 10 000, without the consent of the end user.
Thats why EU have done legalisation in the whole EU requiring all operators to require confirm each € 500, eg for each € 500 spent, the account must be blocked and require re-confirm to start billing again.

A captcha is not only to prevent "bots", its also used to make it clear you are doing a sensitive action, for example lets say deleting some important files, some software might ask you to type "Yes, I really want to delete this file!" in a text box or just ask to "enter 4252562 to delete the file".
To prevent auto-complete from kicking in, it can be good idea to use captcha or whatever.

So this captcha is more as a "confirm activation of pass" so you can't come and complain after this like "wtf? My pass is gone and I haven't activated it" (but in the background some software on your computer activated it). Its a service from the Company to you as a customer.


What unique device fingerprinting information can an iOS8 app collect?

The are numerous opportunities for fingerprinting/privacy leakage at all levels of abstraction.  A good survey can be found on this upcoming PETS paper (full disclosure:  I am one of the authors).

With regard to your specific question, I guess you are looking for something analogous to iHasApp?  There are a number of ways of bypassing Apple's restrictions on, say, private APIs, (see Section 4.3.2 of 1).  FWIW, on Android, this is trivially done through the PackageManager.


What is binary executable randomization?

My guess is you're looking for the term ASLR. The techniques mentioned in the comments are for completely preventing things like ROP gadgets. ASLR will jumble the layout of the program in memory, so an attacker cant easily say "the return address i need to overwrite to redirect the control flow of the program is at offset X past the buffer i overflowed"


How to erase as much as possible an SSD without ATA Secure Erase?

I don't know why you say that SSDs implement ATA Security Erase improperly. Modern ones implement it using SED (which uses an encryption key known to the drive and stored in non-volatile memory for all your data, allowing it to simply erase the key to instantly render data unreadable), while others mark all sectors for being TRIMed, which should effectively wipe the data when the garbage collector gets to them. I'm sure there are some out there which improperly implement it (it's not particularly uncommon), but the same applies to hard drives.

It is true that external USB SSDs and HDDs often have problems with ATA Security Erase, but this is due to problems with USB interfaces not playing nicely with the ATA standard. Additionally, USB flash drives (I wouldn't call those "SSDs") don't implement ATA Security Erase, due to having extremely simple firmware and very low-end microcontrollers (compared to SSDs and HDDs, which have very powerful processors, often dual core, sometimes even quad). An SSD is a full computer connected an FTL and an array of flash chips. A flash drive is a microcontroller with flash memory built in.

As for wiping with userspace tools, none of those will affect the DCO, and none of those will directly affect the overprovisioning space. Only using ATA Security Erase will you be able to erase all of that. It's designed to wipe reallocated sectors (as long as they are not too badly damaged), as well as the HPA. The DCO is just configuration data, so it won't contain anything now that it didn't contain when you got it from the store. If you really want to erase it, you can reset it to factory defaults using the Linux hdparm tool, which has a command to restore the DCO.

Note that badblocks -w writes a predictable pattern, and some SSDs will detect this and compress it, resulting in not actually writing the entire thing to the drive. For data destruction purposes, this is next to useless. You will need to write a random pattern to prevent this.

Just use ATA Security Erase. If you know for a fact that your specific SSD firmware has a buggy implementation, and you can't upgrade your firmware to fix it, then use hdparm to send the TRIM command to all sectors, and use dd (or a similar command like ddrescue or dcfldd) to write random data to your drive, and do this several times. Doing it several times is needed not because there is a way to recover deleted data, but because the overprovisioning space cannot be written to in one pass.

You won't be able to wipe completely damaged sectors. If the drive detects that a sector is taking longer than normal to return data, the data being returned doesn't match the internal checksum, or it has to retry too often, then it'll move it to a known-good sector and mark it as bad. It'll do the same if a sector has simply been written to more than a certain number of times (as they fail after a rather predictable number of erase cycles, often around 2000). The drive can be coaxed into manually marking the sector as good again in order to wipe it or put data onto it (which ATA Security Erase does, and which hdparm can do), but that's only if it was marked bad while it was merely losing health. If the sector was so badly damaged that it cannot return any data, and writes stall indefinitely/fail completely, then there's nothing you or the drive can do. The sector is unreachable without you (or an advanced forensic investigator) examining it physically. You can determine if there are any damaged sectors by using the smartmontools package:

# find out how many sectors are reallocated, and how many reallocations occurred
smartctl -a /dev/sda | grep -i reallocated

An example, if you cannot use ATA Security Erase, to wipe /dev/sda as securely as possible:

# find our max sectors (geometry = 91201/255/63, sectors = 1465149168, start = 0)
hdparm -g /dev/sda

# disable the HPA
hdparm -N p1465149168 /dev/sda

# trim every sector in the drive, from 0 to the max
hdparm --trim-sector-ranges 0:1465149168 /dev/sda

# create a crypt device with a random key, and overwrite it a few times
cryptsetup open -M plain -c aes -d /dev/urandom /dev/sda wipe
for i in {0..6}; do dcfldd bs=256k pattern=0$i of=/dev/mapper/wipe; sync; done
cryptsetup close wipe

# restore DCO to factory defaults (this can mess up the SSD, so do it last)
hdparm --dco-restore /dev/sda

But I would still recommend you use ATA Security Erase instead, if you can:

# initiate an ATA Security Erase which can't be disabled until it completes
hdparm --security-set-pass NULL /dev/sda
hdparm --security-erase-enhanced NULL /dev/sda

And next time, encrypt your data!


Is it possible to make HTTPS 0-RTT with help from DNS?

In theory it would be possible to do a 0-RTT handshake if the certificate is known up-front (like via DNS) and RSA key exchange is done. In RSA key exchange the client creates the full premaster secret (from which encryption key etc are derived) and sends it encrypted with the servers public key (from the RSA certificate) to the server. If simplifying RSA Kx a bit to not include a server random into the computation (see comment from  dave_thompson_085 below) the encryption key can be fully determined by the client it could immediately start sending encrypted data.

But, RSA key exchange is deprecated and is no longer available with TLS 1.3. The problem with RSA Kx is that an attacker could passively sniff all the traffic and if he gets later access to the certificates private key he could decrypt all the previously sniffed traffic. Diffie-Hellman key exchange instead provides forward secrecy, i.e. even if the private key of the servers certificate gets compromised the previously sniffed traffic can not be decrypted.

But, Diffie-Hellman Kx can not be done with 0-RTT since it needs the input from both client and server to compute the shared premaster secret :(


How to know if a web page is valid and not a man in the middle fake page?

Unless you have installed any certificates in your operating system or browser trust store, you can be fairly confident that any page using HTTPS is not the result of a MITM attack. In your particular case, it sounds more like a CSS resource failed to load, resulting in the corrupted layout you briefly observed.

An attacker who is sophisticated enough to perform a MITM attack against a TLS connection without getting you to trust their certificate manually is likely going to also be sophisticated enough to correctly copy a web page design so that it is completely indistinguishable from the original, legitimate layout.

You should verify that:

You have not installed any certificates that you don't trust.
The domain you are visiting to really is the domain you want to visit.
Your browser and operating system are up-to-date.


What you describe is basically a typical phishing attack, where the victim is lured into visiting your evil domain while the victim is assuming that it is visiting the correct domain. The victim is then expected to leave sensitive data which the attacker can grab.

The main difference to the usual credential phishing sites is that the attacker forwards the data between the victim and the original site, so that the victim gets the expected behavior from the site while the attacker gets the secret data of the victim. The idea is not new, see for example New Reverse Proxy Tool Can Bypass Two-Factor Authentication and Automate Phishing Attacks.

There are a some possible protections against this:

Look at the URL and make sure it is the expected one. But this is not as easy as it sounds since similar or look-alike URL's (similar names, punycode attacks, ...) are possible.
Use a password manager which fills in the password to the domain in the URL. This way the password will not automatically be entered into the website and the user will hopefully wonder why this is the case and look more closely at the URL.
Similar newer authentications like FIDO have authentication bound the the actually visited URL and will not be tricked by this either.
If the original site requires client certificates the attack will also not work, since in order to create a TLS connection to the original site the attacker would need not only the victims certificate but also the matching private key, which is kept in the victims browser and not transferred inside a TLS handshake.
The site itself might use some JavaScript to check which URL it is on and in doubt enforce the correct URL or block access. Sure, once the attacker knows that and how this is done he might try to replace the script and spoof the response.


Found solution:

hydra  bbsite https-get-form "/crp/login:username=^USER^&password=^PASS^:F={\"success\"\:false,\"greska\"\:\"Pogre\\\u0161no\"}" -l admin -P /root/Downloads/pass.txt

Needed to add F= for fail login.
Needed to escape \ with \.


In setting up a VM, does the Bridged or NAT configuration provide more separation security?

I was going to post this as a comment but anyway. I've mentioned QubeOS earlier, sounds like something you may be interested in.
I thought I would mention something else: to isolate traffic on a physical network we have VLANs too. AFAIK QubeOS - like other virtualization solutions - uses Linux namespaces to achieve isolation. Although this is somewhat beyond the scope of your question you might be interested in these two concepts.
On Linux you have sandboxing tools like Firejail or nsjail that help you isolate applications by limiting what they can see and access. They work by taking advantage of the Linux containerization functions. If you choose to use a Linux distro other than QubeOS, you can use those tools. Be aware that some applications may malfunction and need a bit of tuning. Example: an app wants to access some data on the file system but it cannot see beyond your home directory. One thing I noticed with Firejail on my system is that VLC was not able to download subtitles (I have not yet bothered to fix this).
The reason why I am posting this is, is that the scope of your question goes beyond bridged or NAT networking, or firewalls. I would even say this is a moot point really. While network design is important there is a lot more that can be done to achieve your goal.
Strong security comes with a number of constraints. You have to find the right balance between security and convenience. If you implement any of the solutions proposed here, you should expect to run into some problems and sort them out on your own, which can be a daunting task for an "average" Linux user.
Regarding QubeOS, I don't have experience with it but I have a colleague using it. Seems that there are still stability issues or routing problems happening, so it is one distro for experienced Linux users. But it doesn't hurt to try.


Is writing shellcode still a valid skill to have/learn?

Yes it's still worth learning.  People who are in the early stages of learning exploit development are not going to come out of the gate knowing everything.  It's good to use the buffer overflow, that you reference and shell code writing to get ppl's interest piqued and to use as a stepping stone to becoming a professional exploit developer.  You never know, you may be teaching the next exploit developer genius and learning about shell code development might trigger a new innovation.  So yes keep teaching it.  Besides it's still used.


Password protect an excel file for a period of time?

A file is just a collection of bytes. It cannot do something to itself on its own.

You need an access restricting application, or use what is available.

Because it is an excel document, any weird solution you come up with can be circumvented just by saving it locally unprotected or copy pasting.

But if you still want to at least try, even if it isn't perfect, try using access controls through sharepoint. You can hand out temporary access or manually turn it off for someone/everyone after a certain period of time.


Can a website download malicious content to my Windows computer without my permission or awarness?

Latest version of Firefox?  Not that I'm aware of, though in the past there has been at least one remote execution vulnerability that could be used for surreptitious downloading (though I'm not aware of it being used for that; rather, it was used to unmask TOR users).

Historically, the "download without your knowledge or consent" browser was Internet Explorer: ActiveX controls were originally intended to be downloaded automatically, and even once Microsoft realized this was a bad idea, there have been various exploits that would let attackers bypass protection.


Is having a GUID in a https url secure enough?

A session id should be a Cookie parameter,  and should never appear in the URL.  Any value in the URL A will show up in the referer header,  as well as access log files.   A web application will end up transmitting authentication credentials to other websites,  and storing them in plaintext on the filesystem.

Additionally, when you pass a session id in the URL, you open the door for Session Fixation.


Techniques for ensuring verifiability of event log files

This is an excellent and important question.  There are several important techniques to know about:

Remote logging. Rather than store the log entries on the webserver, the webserver should be configured to send each log entry over the network to a log server.  The log server should be a custom machine, configured for a single use (log recording only), and hardened.  You should carefully minimize who has access to the log server, firewall it off from the outside world, and make sure it is running a minimum of services.  This will help prevent tampering with logs after they are generated.
Hash chaining. Another important technique is to use cryptographic methods to protect the integrity of log records, once they are stored.  A log entry should be a pair Xn = (Mn, Tn), where Mn is the nth log message received, and where Tn = Hash(Xn-1) is the cryptographic hash of the last log entry.  Use SHA256 or some other collision-resistant cryptographic hash function for this purpose.  What this does is ensure that an attacker can't tamper with entries in the middle of the log, without being detected.  The attacker can replace all the entries in the "chain", or throw away a suffix and replace them with something new, but this constraints what the attacker can do.  Importantly, the crypto ensures that if you write any log entry to write-once media, then the attacker can not change any earlier log entry without being detected.  That's huge.

For more, read about secure timestamping using hash chaining.
Write-once media. If you have write-once storage media, you can write the logs to the write-once media, and that will prevent tampering after they are written.  Unfortunately, the choices here aren't great.  As far as I know, they're basically:

CD-ROMs and DVD-ROMS are write-once, and allow appending if you use TAO mode, but also slightly clunky.
A line printer, printing onto paper, is a surprisingly effective write-once medium, as long as you keep the paper supply fed.
PROMs are write-once, if you use a Manchester encoding.  Unfortunately, PROMs have mostly been replaced by EEPROMs these days, so true PROMs are hard to find.
Wikipedia also has a list of write-once media.
SanDisk has a SD card with 1GB of write-once storage, which is specifically designed for forensics and log storage purposes.

Write-once media complement hash chaining extremely well.  What you can do is store all log entries on some ordinary storage medium (e.g., a hard drive), and then once an hour store the latest log entry (or just its hash) to write-once storage.  This ensures that an attacker who compromises or otherwise tampers with the log server can only modify records going back an hour, as well as (of course) all future records, but not records that were logged more than an hour before the compromise.  That's huge.
Replication. You can store multiple copies of the log entries on multiple servers, to provide redundancy and protect against tampering.  An attacker who breaks into one server and tampers with it won't be able to tamper with the copy on the other servers.

For this to effective, you need the servers to be independent, so that it is unlikely that an attacker can compromise them all.  For instance, you might physically locate the servers in different locations or different machine rooms, set up so that no one person has physical access to all locations.  You might have separate individuals administering them, so that no one person has log-in access to all of the servers.  You might have one log server running on your system, and a replica hosted remotely (e.g., running in the cloud).

Replication complements hash chaining very nicely.  For instance, rather than replicating every log entry, you can replicate just 1 out of every m log entries.  Also, if you don't want to expose private log data to some of the replicas (e.g., ones running in the cloud), you don't have to store the entire log entry: you can store just the hash Tn.  This hash value reveals nothing about the log entries themselves, since cryptographic hash functions are one-way.

I'm sure there is lots more that could be said about this, but I hope this helps introduce you to several technological methods that are available to protect logs.


Nowadays, what is the difference between Cyber Security and IT Security?

NoVa Infosec has a good post on this exact topic.

I tend to agree with the author's view that Information Security is a super-set of Cyber Security.

In my humble opinion "Cyber Security" was most probably a term coined in a late 90's boardroom somewhere by a sales person during his marketing spiel because "Website/Data/System/Internet Security" didn't sound cool enough.

Either way, I don't think you'll ever get the users of these interchangeable terms to agree on a common use.


Is it possible for an 802.1x network (PEAP/MSCHAPv2) to have no certificate?

Is it possible for an 802.1x network (PEAP/MSCHAPv2) to have no certificate (CA, user, or otherwise)?

PEAP/MSCHAPv2 doesn't typically use client certificates, nor does it directly use any CA certificates in establishing a TLS connection (*see below). However it certainly requires the use of a server certificate (PEAP is a TLS tunneled EAP protocol).

  If so, what are the security implications?

The image you provided indicates you are likely using some form of *nix which is giving you two certificate options.

Addressing the second option (client certificate) first, the vast majority of users connecting to wireless with a network using PEAP/MSCHAPv2 will never need this field (I have configured/deployed thousands of APs in numerous environments and have never seen this used personally).

The important option is the first one, the CA certificate field. Why? Because this helps to significantly reduce the possibility of connecting to a fake or rogue wireless network trying to impersonate the one to which you intend to connect.

This begs the question of how the CA certificate helps. Keep in mind that before successful authentication to the network, your client has no access to the network or the resources on it. The AP or wireless controller acting as the NAS (network access server) is proxying the connection from your client devices EAP supplicant to the RADIUS authentication server. The CA certificate is being used to help validate the identity of the RADIUS authentication server to which your EAP supplicant is authenticating.

Generally speaking, the EAP supplicant must make a decision on whether it will send your username/password to the authentication server without being connected to the network. This means it is only able to work with information it has and information it is given by the authentication server, it can't go out on the Internet to check another source until after it has authenticated and it is too late to withhold your username/password.

The EAP supplicant does this primarily by checking two things (with a couple options present in many EAP supplicants like Windows and OSX, but often not on mobile devices like tablets and phones):

Is the certificate provided by the authentication server a valid certificate issued from a CA trusted by the client device?
(Optional) Is the certificate issued from the designated CA(s) in the EAP supplicant?
Does the hostname listed on the certificate match the hostname given by the authentication server?
(Optional) Is the hostname given by the authentication server one of the hostnames allowed in the configuration of the EAP supplicant?

The other options for the EAP supplicant are to either have the OS prompt the user to "check and approve" the certificate (bad idea) or to not validate the certificate at all (worse idea) before sending your username/password.

So providing the CA certificate in your EAP supplicant configuration will help by allowing it to use #2 above to validate the identity of the RADIUS server in addition to #1 and #3. You should be able to get the correct CA information and/or certificate from your IT department.

Note: portions of this answer were copied from another of my answers.


Can an iPhone be hacked during a phone call?

While not theoretically impossible, this is highly unlikely.

For this to happend there would need to be a vulnerability in iOS that could be leveraged for  this. While there are vulnerabilities in iOS (and in any software), unless I have missed something there is nothing that could be used for an attack just through a phone call.

That does not rule out that there is an unknown vulnerability, a so called zero-day, that makes this possible. By definition we would not know about that. However, I would say that such a vulnerability is quite unlikely, and if one was discovered it would be considered a big deal and be all over the tech news. Apple would be embarassed and forced to quickly publish a patch to fix it.

If such a vulnerability were found, it would probably be used primarily against high value targets (threats to national security, government officials, celebrities) and not against random people. Such a golden egg is valuable, and you would not want to risk it being discovered (and patched) just to hack low value targets.

As an example of a similar vulnerability I should mention Stagefright. By leveraging a bug in a video library it was possible to hack Android phones just by sending an MMS with a malicious video file. The phone would get infected as soon as the MMS was opened.

But to conclude, this is not something I would spend time worrying about when I recieve phone calls.


This is a vulnerability. If users have JavaScript disabled, their passwords will not be changed to dots, and thus they are vulnerable to shoulder surfing.

As user @Question Overflow points out in their comment to your question, clicking outside the field would also display the password. Which means a co-worker could see the user's password by taking their mouse for a moment - even accidentally.


Is it safe to abandon a free webmail account that has been in use for a significant amount of time?

No. Never close email accounts that are associated with you or any other accounts you have/had.

After your address is free, somebody can take it and use it to recover other accounts, mess your relationships with old contacts, or even use it to commit illegal activities (death threats to politicians, subscriptions to child porn sites, etc..), and if the email address can be traced to you, you'll get yourself in troubles.

My advice is this:

Change your password to a randomly generated and long password. Save it in your password manager.
Learn your service provider's inactivity policy. Google will close accounts after 9 months, Hotmail after 360 days, Yahoo after 6 + 2x months (x is the age of your account in years).
Schedule a repeated event in your calender to remind you to login to your accounts so they don't expire on their own.


Does the TOTP Algorithm rely on the client time always being synced correctly?

Yes

  What happens if for some reason a cell phones clock / calendar is off by a significant amount of time? Does the TOTP (Time-based OTP) algorithm generate an invalid token?

They would be unable to authenticate correctly. This is not exactly an invalid token, just a token for a different time.

  do time zones play a role in the token being correct

No

  does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?

No. A NTP server is a way to make any of them to get the right time, but your grandmother manually introducing the current date and time (and the device being configured in the right timezone) would work as well.

  suppose there was a 5 seconds differential between server time and client time and my grand mother was typing the the code on her phone, and just taking a long time. How would be assess the amount of buffer time the user has to type the code and whether it's correct or not.

The server can be a bit lenient by accepting a few time steps around the right one (from the server POV), and using a not-too-small time step.

For example, with a Time Interval of 30 seconds, and accepting 3 TS above or below the server one, it gives your grandmother 1.5-2 minutes to type it. Increase it to 10 and you would give her 5 minutes… It's just a matter of determining for how long you want to accept them. But conversely, that allows a greater attack window to fraudulently use such code.

Regarding the clock skew, note that you could record the difference between expected and provided codes and extrapolate the expected skew from that. If at day 1 10:00, the user provides the code for 09:58, and the next day the code for 09:56, it could infer that it has a clock skew of 2 minutes per day, and adjust accordingly the server expectation for this user to old values that would otherwise not be used (properly resetting when the user clock is "fixed"). This calculation increases the complexity noticeably, though. Most of times, I don't think you would generally need to do that.

  Also how are all clients ensuring that their timestamp starts at the same time that the server epoch instant starts?

The algorithm they both agree to use, set a given time from which the instant starts (typically the Unix epoch).


Is it possible to bruteforce a file encrypted with a keyfile?

First I need to point out that Hashcat would not be the right tool for the job. Hashcat works on hashes, and OpenSSL does not store the hash of the key. Instead, you would need to have at least one block of known plaintext, after which you can attempt to brute force a key that results in that plaintext being encrypted into the ciphertext that you see in the file. There are other tools that can do this.

However, I believe you are misunderstanding how the command you have specified actually works. Unfortunately, OpenSSL does not take keyfiles. When you give it a password in the form of a file, it takes only the first line as the password. This line is processed exactly as if you passed it via pass. That is, it is hashed once with SHA-256 to form a 256-bit value that is used to key AES. Because the file you are using is binary, it is very possible that a newline character (0x0a) is one of the first bytes.

If a newline byte happens to be within the first eight or so bytes, it will be absolutely possible to brute force the resulting encrypted file. The probability that any given byte is a newline is 1/256. The chance that a newline is present in the first eight bytes is only 1/32. This means that there is no guarantee that it will not be possible to brute force a file that you encrypt improperly by passing a binary file as the key.

So, how would you do this correctly? You'd want to hash the keyfile yourself and pass the hash as a key to the OpenSSL command. This can be done easily using common utilities:

pass=$(sha256sum keyfile.key | awk {'print $1'})

You can then pass this key to OpenSSL by using -pass pass:$pass. This will guarantee that the entropy of the key will be no less than the entropy of the keyfile you give it. For a 4092-bit keyfile, hashing it with SHA-256 would result in a 256-bit key. Brute forcing that would require going through up to 2256 cipher operations which, as the other answer mentions, would not be possible to complete before the universe itself ends, assuming of course the 4092-bit keyfile is truly random.


Do yourself a favour, don't try to invent your own password hashing functions. In the field of cryptography in general, and of password hashing in particular, amateur constructions are almost invariably weak, because you cannot test for security. Any programmer can make some code which is sound, i.e. which works, but no programmer can make sure that what he produced is secure.

Professional cryptographers cannot invent secure algorithms by themselves either; however, they know it. So when they produce a new algorithm, they show it to their fellow cryptographers, who do their best to try to break it. If the algorithm survives for sufficient time (several years), then the algorithm is deemed "probably secure enough to be used in production".

Unless you have your own cryptographer team and can afford to wait for a few years, you really need to rely on existing password hashing functions which have undergone this treatment and are still alive to talk about it. This basically means bcrypt or PBKDF2. More details here.

Also, don't use password.getBytes(). That getBytes() method uses the default charset, which depends on the current locale. This method is a great way to make code which breaks when used in another country. Instead, use an explicit charset, as in password.getBytes("UTF-8").


That is not what DANE is invented for.  The TLSA records are to give extra security mainly to connect to transport endpoints (say, TCP ports) on named hosts, so that the certificates for host names can be independent of Certificate Authorities.  With DNSSEC, this can be achieved in a cryptographically secure way.

Some people consider it a disadvantage, that someone controlling one level of domain names can control all names AND certificates present on those names.  Actually the owners of the root domain (.) can securely fake any host name and with DANE, a secure certificate as well.

RFC6698 explains it this way:

DNS-Based Authentication of Named Entities (DANE) offers the option
to use the DNSSEC infrastructure to store and sign keys and
certificates that are used by TLS.  DANE is envisioned as a
preferable basis for binding public keys to DNS names...

There is (at least one) related proposal of storing the location of user PGP keys in the DNS of their mail domains in TXT records, but it's main purpose is to make it easier to find such a key, not to actually verify it.

There IS a proposed standard RFC4398 to actually store the certificates, but as it was created before DNSSEC was widespread, it does recommend against storing whole certificates if they would cause the UDP response to be bigger than 512 bytes.  It doesn't seem to me it's in wide use either.

Since all user verification occurs in server software requiring additional configuration, there's usually little need to expect official CA issued client certificates, and/or a standardized way of storing additional copies of the said certificates.  You're actually free to implement any such verification in your program/site.

If you think the CA compromise may make the user certificates invalid, you it may be easier add each user certificate individually as a trusted certificate instead, for example.


Can a salt maintain pseudo-randomness after being modified?

Simply changing the representation of the message shouldn't reduce the entropy given the underlying meaning of the data shouldn't be altered. So for example, you could encode it into Base64 or ASCII without issue.

However, to answer this question generally:

  How much can a function (such as the one below) modify an initially
  random string before that string

It's more of a concern how you modify the data rather than how much the data has changed. If you do anything which makes the data more predictable then you'll compromise the security of the random value. For example, you could safely invert the bits of the string, but if you went through any removed any bit sequences that didn't correspond to an ASCII A-Z character then you'd be making it less secure.

In your case, I wouldn't implement my own encoding scheme - I'd just use Base64.


lsof shows that the executable has been deleted.

Looks like https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1732964 shows a similar bug where the dhclient gets left running.

Might be worth checking:

systemctl status --no-pager cloud-init-local.service --full

And see if that reports the process?

Looks like you've hit the same bug, where a temporary copy of dhclient get's left running.
The bug report suggests they've fixed it - I'd suggest updating your server.


Is Apple's AirPort Time Capsule vulnerable to ransomware?

Technically, the Time Machine content is as vulnerable as the content on your computer. It depends of course on the exact implementation of the ransomware, but you have to assume that when they target Mac OS X, they will target this well-known backup solution as well.

In fact, I read some reports recently that suggested the ransomware "KeRanger" that became known through a breach on the Transmission website was in fact already trying to encrypt Time Machine backups as well: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/

So, you would have to assume that yes, ransomware in the future will do this and you can't rely on your Time Capsule backup. Even if you only sync the backup once a day - it would be trivial for the ransomware to wait until it can encrypt accessible backups as well.

There are some Apple knowledge articles about how to secure your Time Machine backup (below), but they will not be of much help, because they are intended to encrypt your backup from other people. You, as the user, will still have access. It is possible that accessing this data requires user authentication, but the ransomeware could still encrypt the complete backup. This would take time of course, but it's not unthinkable. An alert user may notice this and take counter measures, but the ransomware could also just delete all your backups instead.

https://support.apple.com/kb/PH18852
https://support.apple.com/kb/PH18836

So, you see the weak-point is that this data is easily and constantly accessible. It will only be a matter of how aggressive the attacker wants to be.

Alternative Solutions

One counter-measure would be to regularly create CD/DVD/Blue-Ray backups. It may be a bit old-school, but I want to see the ransomware that can break into my Backup - CD collection ;)
Another could be to use an online backup service. Ideally, you would want one that stores multiple versions of your files (like Time Machine does), so even if all the old files would be pushed as encrypted copies to the online backup, you would still have older versions accessible. Now, you could say the ransomware may also start trying to delete that online data, but hopefully this would require them gaining access to your backup account.
If you want to continue only relying on the Time Capsule, Mac OS X does have a fairly good rights management system - but note that this is worthless if the ransomware manages to gain admin rights through some security vulnerability (I would say that's something most attackers would want to do). Either way, you would first make sure your own primary user account is not an admin. Second, you would setup the Time Machine from your (secondary) admin account. Third, you would require password access to the (encrypted) Time Capsule disk and make sure this password is different to your WiFi password. Then, make sure you never enter that disk password in your primary, limited rights user account.

[EDIT]

Of course this list of alternatives is not(!) exhaustive. There are a million options to secure your files, but in case it helps anyone, I might add a few more options here that you can use for free today.

One thing we will assume is that the attacker is really only interested in your personal files and you are really only interested in protecting your important personal files. Now, the attacker doesn't know which files are important or not, they will just encrypt everything in your home folder ending with .doc / .pdf / etc. That means you don't have to backup your entire hard drive to protect yourself from crypto ransomware.

Backing up your important (text) documents really shouldn't be a problem today. You can use countless online storage services with free storage quotas.

If you are using Dropbox or a similar service, make sure that you don't have these folders actually constantly syncing, though or can at least restore deleted files / older versions online somehow. You don't want the attacker to delete your files and then Dropbox to conveniently also delete them on your cloud storage.

Collections of smaller project files could easily be put into a git repository and uploaded to Bitbucket (or alternatively to Gitlab or Github).

Make sure you are using a private repository here. Technically, git is intended for version control and works best with simple text files, but nothing prevents you from putting PDF files in here. This option is probably more suitable for advanced users.

Photos and Videos can be synced to numerous (free) online storage solutions (including Google Photos, Flickr, Shoebox, etc).

As with the dropbox situation, try to make sure that your online copies can't easily be deleted.

Use write-only folders as a primitive measure. Under Mac OS X you may have seen a folder called "Dropbox" in your "Public" folder (long before the other Dropbox Could thingy was a thing), which is Write-only for other users.

The idea would be to have another user on your machine that has one or more of such write-only folders available. You would regularly dump your important files into that folder. The folder can not be read by you, so ransomware running in your primary user account, hopefully won't be able to look inside.


Is the security seal on samsung phones proof that the phone has not been tampered with?

No. They exist primarily to make you comfortable with your purchase.

As Steve noted in his comment, most anti-tamper seals are actually easy to tamper with. The attacker just needs to dedicate some time to defeating that particular make/model of seal.

This is similar to standard door locks, which you probably have on your house. Any decent locksmith or a well-equipped thief can compromise a standard lock in a matter of moments. Depending on where you live, there are likely dozens (if not hundreds or thousands) of people who could walk into your house on a whim.

The seals may have a deterrent effect on casual handling, but they are completely ineffective as a security measure. There are some anti-tamper products that are truly difficult to defeat, but no one is spending that kind of cash to "protect" consumer products.

This would be disparaged as security theater if anyone seriously claimed it offered some measure of protection.


Getting data from AWS Secrets Manager at deployment (ENV variables) vs. at run-time (e.g. aws-sdk)

There's 3 key differences I can think off:

Using ENV variables typically means they will be in plaintext and visible in the GUI to anyone that can view the function. Reading them at run-time, means that only those principals with access to the secret in SM can view it.
If you wish to change the secret (e.g. rotate the DB credentials), then using ENV variables you'd need to redeploy the function. This is to ensure any running functions referencing the older variables gets reset.
Also, by calling SM during run-time, there will be a log into Cloudtrail of when the function pulled down the secret, but with ENV variables, it'll only be logged when you deploy the function (because that's when it was pulled down).

Now some quick caveats, even for calling during runtime, you'd typically call it during init time (outside your handler) rather than on every invocation -- otherwise you'd be charged for each invocation. But if you do this, you'll only log the first call in Cloudtrail, and you won't be able to rotate the password consistently :(. I understood RDS Proxy allows you to store DB credentials at the proxy rather than at the lambda function, but haven't explored this yet.

KMS allow for encryption of ENV variables as well -- again not something I've explored though.


You can use source code as password.

However I'd strongly recommend against using source code as a passphrase.
The reason for this is entropy.
Passwords / passwphrases need to provide lots of entropy (100 bits+) and programming languages usually pose severe constraints on the formulation of instruction thus resulting in less entropy per character than even with a standard passphrase.

What may be possible aside of that, you can use source code files (100 lines+) with lots of complex instructions and non machine-codable as keyfile.


Looking at http://wiki.squid-cache.org/ConfigExamples/Chat/Telegram
It seems like telegram's servers are using two ip blocks :

149.154.164.0/22
149.154.172.0/22

I would assume blocking all traffic to them should suffice.

Edit, did a more thorough check and it seems like there more as's listed on telegram:( searched telegram asn here: https://beta.mxtoolbox.com/supertoolmobile.aspx)

As Number   As Name CIDR Range  Monitor
59930   Telegram Messenger LLP  91.108.12.0/22  Monitor this
59930   Telegram Messenger LLP  149.154.172.0/22    Monitor this
62014   Telegram Messenger LLP  91.108.16.0/22  Monitor this
62014   Telegram Messenger LLP  91.108.56.0/23  Monitor this
62014   Telegram Messenger LLP  149.154.168.0/22    Monitor this
62041   Telegram Messenger LLP  91.108.4.0/22   Monitor this
62041   Telegram Messenger LLP  91.108.8.0/22   Monitor this
62041   Telegram Messenger LLP  91.108.56.0/22  Monitor this
62041   Telegram Messenger LLP  149.154.160.0/20    Monitor this
62041   Telegram Messenger LLP  149.154.164.0/22    Monitor this


Does WhatsApp have a golden key to decrypt messages?

No, it's implausible that WhatsApp owns a key to read your end-to-end encrypted messages.

WhatsApp implements end-to-end encryption per the Signal protocol which has maintained a good reputation in the security community. From their security whitepaper:

  WhatsApp messages, voice and video
  calls between a sender and receiver that use WhatsApp client software
  released after March 31, 2016 are end-to-end encrypted.

  The Signal Protocol, designed by Open Whisper Systems, is the basis for
  WhatsApp’s end-to-end encryption. This end-to-end encryption protocol
  is designed to prevent third parties and WhatsApp from having plaintext
  access to messages or calls. What’s more, even if encryption keys
  from a user’s device are ever physically compromised, they cannot be
  used to go back in time to decrypt previously transmitted messages.

The last point refers to the property of forward secrecy which the Signal protocol provides by implementing the double ratchet algorithm. This means that even by compromising the current session, WhatsApp wouldn't be able to decrypt any past traffic - there just is no single key that could be used to "decrypt all your messages". So the claim make no sense considering how the protocol works.

That said - while the Signal protocol is open source, the WhatsApp client from your app store is not. If you distrust them to a degree that you expect WhatsApp to ship a backdoor routine in one of their updates, then you'll have to find an alternative messenger to trust.


You seem to fall under SAQ A.  Let's review the list of criteria that determine a SAQ A merchant:

SAQ A merchants confirm that, for this payment channel:

Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;

You don't say this explicitly, but it's implied.

All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;

You state this explicitly.

Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;

You state this is the case.

Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely
on a third party(s) to handle all these functions;

This is implied by what you've said.

Your company has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder
data are PCI DSS compliant; and

This is what you've said.

Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

It's highly unlikely a processor would give you receipts with cardholder data.

Additionally, for e-commerce channels:

The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated
service provider(s).

And this is what you say you're doing.
I agree with you, it sounds like a SAQ A environment.  I would push back and ask the risk management group to explain which criteria of SAQ D they feel you fall under.  The chance that someone could hack your website and change the link is not something that triggers a SAQ D categorization; if that was the case there would be no SAQ A at all.


gpg: Every private key export (of the same key-pair) is different

The exported private keys are encrypted using a password (by default, at least). This means that the private parameters have been encrypted with a key derived from that password plus a randomly generated 8 byte salt. The standard modes of operation for the chosen cipher (like CFB or CBC) also have a random IV (of the block size, so 8 or 16 bytes, depending on whether CAST5/3DES etc. have been used or AES).

Both the salt and the IV will modify the bulk of the private key to be quite different. So it's by design, to hinder some password bruteforcing attacks (always the same salt would mean we could precompute tables for common passwords and dictionaries etc.)


How can I compare GPG encrypted files in order to upload only the ones that have changed?

You can't compare encrypted file contents if you're using gpg.

You have two ways forward that I can see:

Build a hash (say, sha256) of each file before you encrypt it and store it somewhere. Compare the hashes instead of the files. This might become a performance bottleneck if your files are very large. You can check whole trees by building hashes of hashes kind of like git does it. I have a python backup script that does this to detect changes in a large file base; you can have the script if you're interested. You'd have to add an encryption step to it, though.
Look at the modification time of the file content (this is stored by every filesystem along with the file content) to find out whether a file is newer than another one. This is incredibly fast, but you need to take care to get a working system.

However, no matter which way you go, the following problem (from your first comment) will haunt you:

  But I'm still confused as to when the comparison of timestamps should happen, and between which groups of files. [the emphasis is mine]

This is a fairly difficult problem burried in every sync scenario: If you have two sets of files (e.g. two file trees), you need a way to figure out which files in tree A should be compared to which files in tree B. This isn't a problem when you just modify file contents, but what hapens when you add a few files, rename others and delete still others? You basically need an algorithm to determine the edit distance, and a tree editor (to determine and apply a small, or the smallest, set of operations that will turn tree A into tree B). I believe this is an O(n^2) problem and it's an algorithms question, not a security question (e.g. you should ask it on one of the stackexchange sister sites).

Also, if you want your solution to work for file trees, not just a single folder, I doubt you can solve this with a small batch script; like I said, I did something comparable for backup purposes and my script has grown to considerable size (e.g. thousands of lines).


Is the `ssh-agent`'s DSA signature deterministic?

I do not observe this behaviour here. I use ssh-agent from the openssh-client package of Ubuntu 12.04, i.e. "OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012". I modified the Python script to select my DSA key instead of my RSA key (did you do the same ?) and I get, as expected, randomized signatures (no need to even restart ssh-agent, two successive signatures are distinct).

It is theoretically possible to make deterministic DSA signatures through a process known as derandomization, which basically means that the random value k is no longer generated randomly, but with a deterministic PRNG seeded with both the message to be signed (or its hash) and a secret key (which can be the DSA private key itself, or a symmetric key stored along the DSA private key, if there is room fur such an extra key). There are a few subtleties to mind, because the k value must be selected with unpredictable uniform randomness. There is a draft RFC on that subject, but it is still quite new: I wrote the first version on March 2011. I am not aware of any other standardization effort on derandomization of DSA or ECDSA. Usually, when a DSA signature system appears to be deterministic, it is because of a very serious flaw in the random number generator (such as happened to Sony for the ECDSA signatures used in PS3 software).

Are you sure you are really using a DSA key ? A DSA signature has length 40 bytes in SSH (two 160-bit integers, since SHA-1 is used as hash function), whereas a RSA signature will be larger (128 bytes for a 1024-bit RSA key).


Vulnerability scanning applicability for PCI DSS

Absolutely not.

If your goal is just to gain PCI-DSS compliance, you're assessing the situation incorrectly. Compliance should be a by-product of good security, and regular penetration testing and vulnerability scans are an invaluable part of that.

As an example, let's say a 0day is released for Windows XP SP3. There's a good chance you won't catch the news, and you'll be oblivious to the potential problems. Regular vulnerability scanning will alert you to that problem as soon as the scanner is updated with a detection routine. This is critical to keeping the barrier to entry on your network relatively high.

If cost is a major factor, it's time to present your case for a budget increase. You need to weigh up the potential damage and risks, and make a strong case as to why you need to be doing these scans.


Security risk of adding a HTTP Header with server identifier

Does this disclose more information to a potential attacker?  Yes.  Does it make you vulnerable to an attack that you weren't vulnerable to otherwise?  No.  You may have helped them attack you a bit quicker.  However, they still have to find a flaw to exploit.  Really, you are just as secure as you would have been without using a load balancer (or more correctly you are as secure as using one server behind a load balancer as the load balancer could be attacked as well).  Is the point of the load balancer security, or to allow more load than a single server could handle?

Now, you probably already log access requests in log files or a database of some sort; typically storing things on each server like IP/time stamp/GET request/HTTP status, Response Size, and User Agent string.  Would it be possible in debugging to run a quick grep over the relevant logs to identify the server that's not performing?  E.g., change the User-Agent in your browser while testing to something like "DEBUG_14_Feb_2013", search for that User-Agent in all the logs and identify the server + requests that are malfunctioning based on response size or timestamp or IP?

Or maybe you could turn this HTTP header on, but only while debugging by having a flag set received from the load balancer (or alternatively set at each server), so its only displayed when you are actively debugging an issue?


Is it wise to remove redundant self-signatures from my PGP key?

In fact, when importing the public key, duplicate signatures are automatically removed. Because of this, anyone who imports your public key will already have a copy without the redundant signatures. Removing them yourself just makes it so that they do not need to do it themselves.


Double Submit Cookie Implementation questions

CSRF protections are there to protect you from attackers making the browser automatically do things on your behalf. In this instance, the client has to include the request header manually (presumably through JavaScript). A normal browser request via form POST or linked GET will never include this header, so a CSRF attack cannot take place.

That's all this protects against. You're screwed if the attacker has a way to steal the cookies because they can just impersonate the user and do whatever they want. Or put another way, you also need to find a way to protect the cookies from being stolen.


With CallerID Spoofing, the number shown can be anything the caller wants it to be. Usually these calls are trying to identify something (modems, fax machines, voicemail box, etc.) Hard to know exactly what this particular one was, but often they are harmless just annoying.

There is an app by Whitepages called "Hiya" that you can download that tries to do some checking of the incoming number and x-ref it with known scammers. It will even do some blocking for you if you set it up.


Allowing unauthenticated user access web page information

In essence, you are using your login system to accomplish two separate goals:

Authenticate regular users
Give guest users access to otherwise authenticated pages

As a general rule of thumb using one thing for two purposes tends to cause its own problems in the long run, and so if nothing else the SRP suggests this is a bad idea.  There are certainly plenty of ways this can cause problems:

You'll still need access controls to make sure that users of this guest account aren't granted access to other API endpoints that are not supposed to be accessible to them.  This, in fact, would probably be my biggest concern: when writing a new API endpoint it would be very easy to forget "Hey, we have guest users that use this other special login" and therefore forget to prevent access to a new API to said guest users.  If that API happens to deal with sensitive information, then you may effectively end up with a public and critical data breach.
By allowing many users to share one account, you make auditing and data access logs much trickier to implement effectively.
If you ever need to change the credentials for the guest account you can't do so without logging out all active guest users

There are two alternate routes you could take:

1. Separate endpoints that don't require login

This has plenty of advantages.  Granted, you do have to create a separate set of endpoints, but it will add a layer between your unauthorized users and your authorized systems.  This both makes it harder for them to potentially find security weaknesses (since they are limited to a much smaller subset of your system) and also makes it harder for your developers to make mistake.  When there is clear separation between, e.g. "This code is for authorized users" and "This code is for unauthorized users" then it is harder for someone to forget what part they are working on and make a security blunder as a result (note that I said harder - not impossible).  This is will make it easier to properly secure your endpoints, even if you can't precisely quantify the end result.

2. Separate guest accounts for each user with restricted access controls

There isn't a ton of background in your question, but based on what little I can see this probably won't make sense for you.  Still I figured it never hurts to mention things.  Another option is to simply create a separate guest account for each "guest" user of your system.  This works best if your system already has clear access controls in place (so you can confidently lock such users out of places they aren't supposed to be) or if used in conjunction with a separate set of API endpoints (i.e. guest users are automatically locked out of all endpoints except these public ones).

You end up with a bit more code to manage this way (as opposed to just having some completely open endpoints) but it has some advantages:

You can more cleanly track guest users in your system, presuming that you are already tracking your users based on their logins
If you have a concept of "converting" these guest users into full users of your system, you'll already have the process half done when it comes time for conversion, and then you will be able to easily track a user's history from before they even "officially" signed up.
Depending on how a user becomes one of these guest accounts, your "public" endpoints don't have to actually be fully wide-open.  I.e. if a user clicks a button to "Accept terms and conditions" and then is automatically becomes a guest user, and you have to be a guest user to access these "public" pages, then you will have effectively kicked out most bots and automated scraping systems from your endpoints.


Possible bug, check what's in /var/log/chkrootkit, or just go and purge apt-get purge chkrootkit or try to reinstall: sudo apt-get install --reinstall chkrootkit


Nmap write output only when all scanned ports are open

I don't believe that nmap has this capability natively within the program, however it would be relatively easy to achieve this goal with a scripting language after the scan has completed.

For an example when using Ruby you could use something like the ruby-nmap gem to parse your output and return a list of hosts that have those three ports open.


Phishing e-mail replied to internal email. What is compromised?

Have you already considered that it might just be coincidence? If the subject was something common, it might not even be a compromise, just a lucky guess. If it wasn't something that obvious, how about these?

In decreasing order of probability:

One of your employees is doing the phishing
Do you have a BYOD policy? Maybe one of their phones has been compromised. Or their laptops for that matter.
One compromised system belonging to any user on the domain (keylogged maybe?)

Honestly, just wait it out. If you've reset all passwords, that should lock out the attacker, at least temporarily. Next go about scrubbing all their computers and remove anything suspicious. If this fails and you receive any more spam, begin resetting passwords in batches - and keep narrowing down your suspects (painful, do not recommend).


SHA256 hash can be used to decrypt data?

It generally on your threat model!

For example, if the two files are identical before encryption, then correct encryption will yield two different files, but two identical hashes before encryption. As a result, an attacker can know that these two encrypted files, while looking different, have the exact same plain text. Is that a problem for your use case? You have to decide.

Further, it depends on the kinds of files you encrypt, and what your attacker knows about them. If these files are in a structure known to the attacker and have very little entropy, then a brute-force attack could be a valid attack vector. This, for example, is a problem if your file looks basically like this:

  Employee #1234 received 2501 USD.

Just by plugging in an employee number and brute-forcing the right side, you'd quickly end up with the "correct" sum.

On the other hand, if your files are quite large and very random (e.g. images, videos, spreadsheets, etc.), then a brute-force search becomes infeasible very quickly.


Can malware have its own GRUB/boot-loader and use it to be active?

Obligatory XKCD:

With that out of the way...

The basics of the boot process
First, you need to know how a bootloader works. When the system first starts up and the BIOS is in charge, it initializes all the devices necessary for boot. It then reads the CMOS to find out the correct device to boot from. It opens the first device, and reads the first 512 byte sector (where the MBR should be installed) into memory. Specifically, it transfers the first sector to physical address 0x7c00. If the last two bytes of the sector are 0x55aa, it considers it a valid bootsector, and executes it. At this point, the BIOS is out of the picture, and the MBR is executing. The MBR is far too small to boot most systems, so instead it boots the second stage of the bootloader. All it has to do is be able to locate and execute some data on the hard drive containing the rest of the bootloader. In this case, the core GRUB modules. At this point, GRUB is fully functional and does all its magic to load your kernel and start the operating system boot process. Now, how can malware hijack this?
Hijacking the process
If malware wants to modify your boot process to randomly make you boot with malicious code in play, it can do one of a few things. In order of increasing levels of sophistication and stealth:

It can modify the second stage bootloader or its configuration directly, so when it is executed, it changes its behavior at random, performing malicious actions during some boots.

It can modify the MBR at the first sector on the bootable drive to, at random, choose to load a different second stage bootloader. The different second stage would inject malicious code.

It could modify your BIOS so it loads a different, malicious MBR for some boots. This is more difficult to pull off, but it is possible. BIOS infections are quite rare.

It could modify the hard drive firmware to return malicious data in the first sector randomly. This would require a very high level of expertise, and is exceedingly rare (virtually unheard of).

The displayed symptoms
But here's the important question... Are the symptoms you are describing indicative of any of the above scenarios? Let's look at the symptoms as you described them, one by one:

Your bootloader counted down from 25 seconds, despite you having set the timeout lower.

Your Ubuntu installation occasionally has a blank screen after you log in, or randomly reboots.

It rebooted itself without you commanding it to do so when it loaded GRUB.

Are these symptoms of a bootkit? No. The first issue is most likely a configuration issue. Every update, your Ubuntu installation updates the GRUB configuration file. The configuration file is very complex and has a large number of conditional statements. It would not be surprising if your settings are occasionally overwritten. The second issue just sounds like a bug in Ubuntu. Perhaps a driver for your hardware is buggy. I had an old Ubuntu system that did something similar. An update fixed it. Your third issue sounds like a bug in GRUB, or perhaps a hardware fault. All you are experiencing is the bugginess of software. As bugs are still annoying, you could try reinstalling GRUB, or resetting the configuration. Perhaps look online to see if there are any known errata for your software. Check your system logs to see if it is reporting an application crashing that may lead to the blank screen. And, of course, make sure you are up to date, so you get all the latest bug fixes for your setup.
Malware wants to be stealthy. It doesn't want its presence to be found out. Malware that is good enough to hijack your boot process will be very stealthy, and won't give away its existence through something as tantalizingly simple as a spontaneous crash. So no, this is not malware.


Does the use of CSRF Tokens as a defense mechanism block all Cross-Origin Requests?

Wouldn't this mean that even legitimate cross-origin requests would be blocked?

Use of CSRF tokens and checking of Origin or Referer header does not simply block all cross site requests.  It just means that only requests which have the proper CSRF token or which come from an acceptable Origin are allowed by the web application. Thus it also can be used to allow controlled cross-site execution if this is required.


Why is PKCS#7 used as a response to PKCS#10?

PKCS#7 is a container and can include multiple certificates. When CA responds to client it puts in the container signed certificate and all required intermediate CA certificate you may need to install in order to correctly use the issued certificate.


Only using TLS 1.1 or 1.2 is enough for PCI DSS compliance on transmission of cardholder data (point 4)?

The short answer: Yes TLS v1.1 and v1.2 are suitable protocols for transmission of cardholder data and unless you have identified a gap in the transmission path (i.e. where TLS will not protect the data from unauthorised access) additional encryption will not be necessary.

There is also the following in the Guidance Notes for control 4.1:

  Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.)


Car registration paper stolen from glovebox, what kind of scams are possible?

You asked,

  What should I be worried about as a result of this info leak?

It's hard to give an exhaustive list, but in the end, I don't think that's really the important question to ask - really, the important question is, what should you do now to protect yourself?

Reach out to the DMV and your insurer. Your state's DMV will have a process on how to replace stolen registration documents. The risk of not reporting them as stolen is that the thief may try to impersonate you with respect to your motor vehicle ownership (i.e. they may try to create an online account with the state DMV, or take over your existing account. Or they may try to get replacement plates and impersonate your vehicle, etc).
Ask the major credit bureaus to lock your credit report. This will mean a minor hassle for you if you try to apply for credit any time soon, but it can help protect you from identity theft. The thieves now have your name and address and details about a vehicle you own - while that by itself isn't very powerful information, it may form a piece in a larger puzzle - taking steps to protect your identity can help prevent that.


What probability of injecting invalid data is considered safe?

Xenos' comment is right.

Unless you are a badge-bearing cryptographer, trust the badge-bearing cryptographer and don't implement your own method. You may think your method is secure, but you have no way to really assess that. Even professional crypto guys commited mistakes undermining their process. So use the hard work of the giants before you and use Autenticated Encryption.

It would be interesting to know how you calculated the probability of an attack. Do you have a decryption oracle? Can the attacker use chosen plaintext? Can the arracker have the source code? Is your solution according with the Kerckhoffs' principle? (attacker have everything but the key)?


Is moving a file with "cut and paste" secure?

This depends on whether or not you are cutting and pasting into the same partition, not just the same drive. If you are pasting it into a different partition, then it will actually be copied, and the original subsequently unlinked. If, however, you are moving it within the same partition, only the metadata specifying where the file is located will change. This is the reason massive files can be moved (cut and pasted) within a given partition instantly, even if they are several gigabytes in size.

Note that this also applies to Mac OSX and most GNU/Linux distributions.


What is the application of SHA384withRSAEncryption?

This corresponds to an RSA PKCS#1 signature with SHA384 hash. This means that the data is hashed using SHA384, and that hash is signed with the RSA private key from a PKCS#1 certificate.

In terms of securing data in a database, this would be pretty unusual. However, it could be used to ensure that data entered into the database was generated by the owner of the RSA private key. In the case of an attacker that has access to the database and nothing else, this prevents them from forging records.

The same sort of idea fits in with long term data storage. It proves that the data was not tampered with after being signed.


What techniques do advertisement companies use to get my browsing information, and how can I stop them?

There are several ways I can think of:

Browser-fingerprinting. To stop browser-fingerprinting, use Random Agent Spoofer correctly.
Your IP address. To stop this, use a VPN such as Private Internet Access, and connect to a random IP every time.
Your free accounts. When you connect to free accounts such as Gmail, YouTube, etc., they sell your information to third parties. Associating your fingerprint and known IP addresses helps people track you down. To stop this, quit logging into your free services on your current IP, including VPNs.
Third-party Cookies. Don't allow third-party cookies, like ever. And on some sites, simply don't allow them to use cookies at all.
Canvas-fingerprinting.
Javascript that tracks you. You can disable Javascript, or find an add-on that prevents tracking scripts from loading. Usually, uBlock will do this.
Flash LSO objects. Use an addon such as Better Privacy.

There's a lot of different ways to track you...

Apparently, there are a lot of things I haven't considered. Check Steffen Ullrich's suggested reading.

Also, you should be using uBlock origin.

uBlock for Chrome
uBlock for Firefox

Wear an advertisement-based Tinfoil Hat

I would suggest a mix of the above, but probably take it a step further: set up a virtual machine (such as VirtualBox) that connects to a different host, and use your "free" services on the virtual machine's web browser.

If it's online, and it's free, then the majority of the time, you're the product. How do you think these companies survive by providing free products while having a LOT of staff members? It isn't because of their good nature.

Don't forget to clear all of your cookies.


Syverson's paper (Users Get Routed), What do they mean by "common locations"?

The ability to deanonymize using this method involves correlation among other traffic by your IP.  The more traffic available to correlate, the better chances of deanonymizing.  I believe the use of "common locations" denotes an AS containing many other popular sites, maybe to include gaming servers, StackExchange web servers, CDNs, etc.  Perhaps an "uncommon location" in this context would be an ISP for a more rural area of some remote nation where the target would not be sending much, if any, traffic to.

Edit:  Source for my explanation of how it is correlated, under the "Related Works" section:

  Onion routing is vulnerable to an adversary who can monitor a user’s
  traffic as it enters and leaves the anonymity network; correlating
  that traffic using traffic analysis links the observed sender and
  receiver of the communication.


Is it possible to get an SQL injection without an error coming back?

Yes, it's called Blind SQL Injection, which is quite hard, but not impossible.

If you can query for a lot of true / false values, then it's a Content-based Blind SQL Injection.

Another common method is the Time-based Blind SQL Injection, where you basically instruct the database to perform a time-intensive operation. If the web site does not return a response immediately, the web application is vulnerable to Blind SQL Injection. Mostly, the sleep operation is used.

yoursite.com/index.php?id=1337 and if(1=1, sleep(42), false)

If the page doesnt reload asap, it's vulnerable.


Alternative routes for Incident Response approach other than Windows Event Viewer?

I once had a similar task and I found Nirsoft Mega Report. It combines some of the NirSoft utilities. I didn't find it very useful, since you get a lot of single reports, but not a complete timeline.

End of 2014, I tried to achieve it myself by using the NirSoft tools, running them in unattended mode and exporting to XML. The tools I considered for that were

AppCrashView (maybe someone tried to exploit a bug in an application)
JumpListsView (see what was done last)
RecentFilesView (which files were used last)
UserAssistView
BlueScreenView (maybe some kernel exploit caused a bluescreen)
FirefoxDownloadsView (maybe some malware came from there)
LastActivityView (see what was done last)
ShellBagsView
WinLogOnView (who logged on)
BrowsingHistoryView
FlashCookiesView
MozillaCacheView
SkypeLogView
WinPrefetchView
DevManView (were there devices connected)
IECacheView
MyEventViewer (like Windows Event Viewer)
TurnedOnTimesView
ImageCacheViewer
myuninst
USBDeview (were there devices connected)

From all these XMLs I tried to build a complete timeline. I say "tried", because

I found that the XMLs were not always well-formed. I reported that as bugs, but I was never notified whether they were fixed.
Not all tools provide XML export

Still, all those reports may be helpful.

If you do forensic stuff, consider the following basic rules:

get an image in a forensically sound way
only work on a copy of that image. Never work on the original and never work on the forensically sound image (of step one).


Resolving "This website has been reported as unsafe" (Windows Defender SmartScreen)

I can't find any information on what the process is to get this notice removed.

Your site was clearly visible blocked by Windows Defender SmartScreen. Your problem is addressed in the Windows Defender SmartScreen FAQ or your might just have looked further into the More Information part of the message. To cite from the FAQ:

  Q. If I am a website owner, how do I correct a warning on my legitimate site?
  A.
  You can immediately submit a request for a correction. Windows Defender SmartScreen has a built-in, web-based feedback system in place to help customers and website owners report any potential false warnings as quickly as possible. In Windows Internet Explorer, from a red warning, click More information then Report that this site contains no threats. This will take you to a feedback page where you can indicate you are a site owner or representative. Follow the instructions and provide the information on this site to submit a site for review...


Security scan with, or without, IP whitelisting in the firewall and isn't that introducing a weak point?

Nobody can access the database or monitoring server directly

... as of now.

My opinion is that one must assume a worst case scenario, where all the obscuring/protection layers are gone (whether this is because of a hack or a mistake) and the bare application together with its stack is available.

On top of that you may run into issues when scanning through a firewall (resources exhaustion). This is something which you can usually fine tune but there is a risk anyway. I once ran zmap by mistake against networks behind firewalls and it did not end well (this is an extreme case).

The same question arises when discussing whether to pentest with a WAF on or not. Again, I find that knowing there is an issue and relying on virtual patching / blocking is too risky.


How difficult is it for ISPs to understand a user is using VPN?

how difficult is it for an ISP to know that a user is using VPN

Actual implementations of VPN vary and don't always mean that the user always hits the same IP address. But still an ISP or anybody else having access to their infrastructure could detect atypical traffic patterns (like nearly no web access but lots of other traffic) and thus conclude the use of VPN or other techniques to hide the real traffic.

  favorite
  If a user is using VPN, how difficult is it for an ISP to know that a user is using VPN ? If the government demands, isn't it possible for the ISP to provide a list of customers who could be using VPN by making a list of customers who are always hitting a single IP (as the user always connects to the same VPN network) ? My questions may be naive & hypothetical, but I'm curious to understand if there is anything stopping the ISPs from doing it.

  If the government knows we are using a VPN, won't it get more attention from them.

Depending where you live this might happen.

  people keep saying using VPN is more secure

VPN makes the data transport itself more secure by encrypting the communication and this way protects against sniffing by a man in the middle. Depending on how suspicious your are this might lead to an increased risk of getting hacked directly in order to get access to the data before encryption. Or in cases where encryption is forbidden by law it might increase the risk of getting arrested.


Is constantly downloading large amount of files from a web server considered DDoS?

I'd say no. A DDoS is a distributed denial-of-service attack. Writing a program to sequentially download files stored on a server certainly isn't distributed as long as you plan to run the program on a single computer. It's not an attack if a) you don't intend to crash the server and b) there's no reason to believe running your program will do so.

If the goal of your program is to crash the server (and your program meaningfully restricts bandwidth) then running the program could be considered a DoS (plain denial-of-service attack). But even if you don't intend to crash the server but there's a good chance your program could do so, then your actions could be considered an attack.


Differentiating identical requests from different computers in a local network

If the machines have the same software version of wget and curl and operating system, and assuming that both requests have the same source IP due to the NAT, is impossible to know the source machine from the destination server. Take into account that the only field available on HTTP that could differentiate the machine type is the User-Agent and also this field could be modified and fake it on the source. Hope clarifies

An example on python-curl (wrapper of curl)

User-Agent: PycURL/7.43.0.2 libcurl/7.59.0 OpenSSL/1.1.0i

This User-Agent could vary depending on the python-curl version and on the openssl used.

An example of python requests

User-Agent: python-requests/2.19.1

So if you have two machines with the same version of python-requests 2.19 (for example) but one is Windows and the other is Linux, and only the 2.19.1 is supported in Linux you will know exactly what was the machine, but remember that this information (the user agent) could be modified easily.


Hardening Tor/proxy chain by choosing the relays' countries

... rather about chaining proxies through countries that don't have a good political relationship to make the paperwork a hard thing.

What paperwork? The nodes only know what other nodes are talking to it.
The way to 'reverse' a Tor connection is either by

Infecting the PC through Tor like the FBI did
Running / compromising an exit node and looking for identifiable info in the exit traffic
Running time correllation on the infrastructure used for entry and exit

The only paperwork i could imagine is with #3 but you only need to monitor the entry like this so the intermediate nodes don't matter. The likely opponent, state actors, will probably opt for the first two options. Infecting is easier and more reliable than tracing.


How did stuxnet hid it's files after the infection?

Answer is also simple - inject into Explorer and hook the following functions:

FindFirstFileW
FindNextFileW
FindFirstFileExW
NtQueryDirectoryFile
ZwQueryDirectoryFile
.

Symantec has a bit more in depth explanation.


Help to account all the points of physical access to a rack server to steal software

I think you're not thinking about this clearly.

If you are convinced that the hosting provider is going to try to steal your code, there's a very simple solution: don't deploy your code on a machine with that hosting provider!

If you are convinced that every hosting provider is going to try to steal your code, don't deploy it on any hosting provider: deploy it on machines on your own premises.

That said, I strongly suspect your threat analysis to be mistaken.  I find it hard to believe that there is a 90% probability that every hosting provider will steal your code, if they can get away with it.  There's just no way that is accurate.  If they were caught, the hit to their reputation would be devastating: it would put them out of business.  Reputable providers are unlikely to take that risk.  And, what's more, most hosting providers don't have an interest in your code; they are focused on their hosting service business, and probably don't care about your code.

So I suspect that you have mis-estimated the risk.  But, if you're convinced you've got the risk right, well, the solution is simple.  Just don't use a hosting provider.

You know the old joke:
Patient: Doctor, doctor, please help me.  It hurts when I slap my knee.
Doctor: Well, don't do that then!


In modern TLS, the private key of the leaf certificate won't let you decrypt previously recorded traffic, because modern TLS has DH (specifically, ECDHE) which provides PFS.
So you need to MiTM the connection or extract the per-connection ephemeral keys from the app.


I'd like to point you to open source tools that we use in pen-testing web applications:

Arachni, already mentioned in a previous answer.
w3af, one of the most famous free open source scanners. This one is written in python and have a consistent UI (GUI and CLI). The project is sponsored by Rapid7, owners of Metasploit and NeXpose
Skipfish, a fire and forget command line scanner which excels at crawling and forced browsing, produces fancy HTML reports
OWASP Zed Attack Proxy, the defacto open source web attack proxy. ZAP has an API and integrates code and features of other reference tools like JBroFuzz and DirBuster. It is more suited for semi-automated testing

The following open source tools can help exploiting SQL injection (SQLi) and Cross Site Scripting (XSS) vulnerabilities:

SQLmap: this CLI python tool is ideal to exploit SQL injection flaws, i.e. dump the database, execute SQL commands and even compromise the back-end database's Operating System. It is similar in purpose to Havij and often used in the wild by script kiddies to exploit vulnerable targets
BeEF: the perfect tool to demonstrate the risk of XSS flaws, its new shiny Ruby on Rails web interface allows you to leverage XSS vulnerabilities in order to command victim browsers

There are a lot of commercial tools in the web vulnerability scanning market with prices ranging from a couple hundreds dollars to tens of thousands of dollars. These can get you better results than open source ones and can combine features of open source scanning and exploitation tools. However, you'll always need that chair and blood penetration tester to try and break the logic of the application, something a tool, no matter how much it's worth, can never do.


Prevent cross domain form submission with nonce?

Preventing form submissions from another source is a solved problem, and using a nonce is one of the recommended methods.

For some background, there's a form of attack against web applications known as Cross-Site Request Forgery (XSRF). A cross-site request forgery, in simplest terms, is when someone loads JavaScript on a malicious page that makes posts to another page.  There is more to it than that, and if you're unfamiliar with CSRF, I strongly recommend reading up on it.  (See Jeff Atwood's article in addition to the OWASP article I linked to above.)

The good news is that many web development frameworks already have pre-built mechanisms to prevent XSRF attacks, and they do so by ensuring that posts come from your own domain.  Again, using a nonce is one of those methods.

From the OWASP page on XSRF:

  Related Controls

  Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many
  frameworks (ex, Drupal.org 4.7.4+) either have or are starting to
  include this type of protection "built-in" to every form so the
  programmer does not need to code this protection manually.
  TBD: Add a per-session nonce to URL and all forms

At the bottom of the OWASP page are several references including links to already available mechanisms for addressing this, including the OWASP CSRF Guard, which uses J2EE, .NET, and PHP filters that append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.


MITM without spoofing (Decrypt sites with SSL + HSTS)

No, if you are trying to decrypt websites like facebook, google+, twitter, etc... for login credentials, it will not work. HTTP-SSL/TLS (HTTPS) will encrypt the traffic. All sslstrip does is redirect pages to non-HTTPS versions. So https://www.website.com becomes http://www.website.com. Of course this is very simplified but in turn the end result is un-encrypted traffic. It does not decrypt it. Then HSTS was created to stop this, only HTTPS pages were allowed for said sites. What SSLStrip+ does is redirect to a sub-domain without the HSTS header. For example wwww.facebook.com, then HTTP is allowed. But it works with very few sites because of the AllowSubDomains=True part of the header. This meand wwww.facebook.com is resolved to the DNS IP of regular www.facebook so data is still encrypted. Sorry. If you want I recommend just DNS spoofing non HSTS sites but asking for GOOGLE+ data to continue from your own APACHE server. (If you are on the same LAN) Then you get it anyway, but it is much easier.

Very unlikely.

Or, if you have enough control, theoretically you could install a root CA so your SSL/TLS certificate is trusted. But if you have that much control why not just use a key-logger.


Brute Force Decrypt VeraCrypt - No Rescue Disk - Password Fails

No, knowing the encrypted contents won't help.

This is called a known-plaintext attack and good ciphers should not break when confronted with one.


How to do TLS on embedded devices in a home network?

This can be done by certificates on domain names that point to RFC1918 addresses.

Each device gets its own subdomain (c12345.umbrellacams.com), and each subdomain has its own certificate. When installing the device in the network, it has to send its address to the server in order to update the DNS entry on the subdomain. When the user visits the camera in the browser, they can check the domain name against the serial number on the camera to make sure they are connected to the correct camera.

An attacker can buy a camera and extract the private key from it, but then he can only MitM his own subdomain, c98765.umbrellacams.com, and not other subdomains such as c12345.umbrellacams.com.

When on another network, the domain c12345.umbrellacams.com points to a different device, but since that device does not have the private key of the certificate it can't establish a valid TLS connection.

More details in my blog post, A method to do TLS on IoT devices.


Can anyone help me build a combo file suitable for my problem?

It looks like you may be in luck. Given the positioning the smudge for asterisk 2 is almost certainly a 7. Also the 3rd asterisk appears to be a lowercase rounded character. This narrows the password space down to (roughly) 360 passwords.

Below is a short C# program that I wrote. This will output all possible passwords (currently limited to what I think it likely is). You can extend the character sets as need be. To run this you can download LinqPad https://www.linqpad.net/Download.aspx (I used version 4) and run the part contained in the Start LinqPad and End LinqPad comments as a C# statement. Other wise you can run this in Visual Studio Community Edition from Microsoft (A much longer download). Note that these are both Windows programs (If you need Mac or Linux leave a comment).

Code begins here:

using System;
using System.IO;

namespace maorLostPassword
{
    class Program
    {
        static void Main(string[] args)
        {
        //Start LinqPad

        //write out to desktop
        string path = Environment.GetFolderPath(Environment.SpecialFolder.Desktop);

        //Add the character set here a-z, 1-10
        Array CharacterSet0 = ("abcdefghijklmnopqrstuvwxyz0123456789").ToCharArray();
        //This looks to be a 7, however I will leave this here incase it is not.
        Array CharacterSet1 = ("7").ToCharArray();
        //This looks like a lower case rounded letter add in the ones that you think it could be
        Array CharacterSet2 = ("acdeghopqs").ToCharArray();

        //Write this out to a text file
        using (StreamWriter writetext = new StreamWriter(path + "\\passwords.txt"))
        {
            foreach (char i in CharacterSet0)
            {
                foreach (char j in CharacterSet1)
                {
                    foreach (char k in CharacterSet2)
                    {

                        //Reverse order to print in alp order
                        string password = i.ToString() + j.ToString() + "7k8" + k.ToString() + "d";
                        //write it out
                        writetext.WriteLine(password);
                    }
                }
            }
        }

        //end LinqPad
    }
}

}