How is PasswordSafe different from KeePass/OtpKeyProv?

When using a YubiKey; PasswordSafe uses a Challenge-Response based on HMAC-SHA1 for the second factor. This functionality is included in the original program with no plugins and there is no recovery method. If you lose the key, you lose your data. I believe this makes it more secure.

Keepass can use OATH HOTP mode (with the OtpKeyProv plugin) and HMAC-SHA1 Challenge-Response mode (with the KeeChallenge plugin). Both of these plugins offer a recovery mode where you can recover the database using a long secret. The security of these systems is only as strong as your ability to secure that secret. It's a long string that you would normally want to store in an encrypted container like a password safe...

Sources:

https://support.yubico.com/support/solutions/articles/15000006481
https://www.yubico.com/why-yubico/for-individuals/password-managers/keepass/
http://richardbenjaminrush.com/keechallenge/


Generating a CSR for 32 bit private rsa key

You cannot encrypt anything with RSA which is larger than the key size (minus some padding and header) which means that you cannot sign anything if the signature algorithms results in a value larger than the key. A hash digest is 256 bit for SHA-256 or 192 bit for (already insecure) SHA-1, i.e. way larger than 32 bit.

Apart from that: why do you want to use such terribly insecure small key anyway?


Reasons to place a time limit on entering login credentials?

This seems like a solution geared toward backend session management.

I'm speculating anonymous users don't initiate any sort of session, but a session gets instantiated once you hit the login page. When you log in, it gets noted in your session and you get to use their site and services. If you don't log in within a certain time, they go ahead and terminate your session.

Given the market within which they operate (security) I could see them being a target for DDoSing via resource consumption so this would be more of a resource management solution than anything (prevents the number of open sessions from exceeding a certain threshold).

So it's security for their infrastructure, not any sort of security for your account.


Can an attacker modify data so that the hashing technique cannot detect the change?

Not for any well-known hashes, not even the extremely broken MD5. You're describing a second preimage attack, but virtually every hash known to be "broken" is only vulnerable to collision attacks.

Caveat: if the attacker had any control over the "good" data, then they could use a collision attack to accomplish this.


How can I detect OS by sniffing network traffic?

nmap has the ability to guess the operating system by looking at variations in how a device reacts to TCP/IP probes (see the nmap website for details).

You can also make a guess at the identity of a device by looking at who its MAC address was allocated to.  For example, something with an address in a Hewlett-Packard block is probably a network printer.


File types and ways that can infect Android devices with malware

The key thing to remember about malware on Android is that you have to actually install the malicious app. Malware writers will use increasingly clever techniques to try and trick you into doing just that.

So, can an android app on Google Play be fake or malicious?

Yes, it might be.

What can an Android malware/virus do?

The vast majority of malware on Android is focused on stealing your information, which is obviously a major concern. Perhaps the worst case scenario at the moment is malware that sends SMS messages to premium rate numbers.

There are apps that clone legitimate apps to fool you into downloading them and apps that are malware free when you first install them, but download malware through the update system.

The most common Android malicious apps will do at least one of the following:

Collect and send GPS coordinates, contact lists, e-mail addresses
etc. to third parties
Send SMSs to premium-rate numbers
Subscribe infected phones to premium services
Record phone conversations and send them to attackers
Etc.

If they have the permission they will use it! (ex: If you give access to your camera ... they can use your camera)

Is there anything more dangerous then that?

Yes. Your phone is a mini computer and you install things on it. If one of your installed application has vulnerabilities (ex: Remote Code Execution) maybe a hacker can hack your device if it is on the same network or it can send a specific targeted payload.


Tracking unique web site visits without logging IP addresses

First of all: Why are you so concerned with not storing IP addresses? It's not private data; the OS or NAT router happily includes it with every sent packet. Okay it's kind of necessary, but what I mean is that they aren't really private. Also, random IPs are not really useful for hackers, and it's not a privacy concern when you can only see them yourself.

Secondly, it's not really useful to save IP addresses with the goal of counting unique visits. Not only can one IP have hundreds or thousands of users (like schools), but a single user can also easily occupy a /16 subnet or two (many people's IP changes every few days or so), not to mention laptops and mobile phones. A better technique would be session cookies, which are unfortunately restricted to the browser (and thus one device, so not counting people but the number of browsers really), but it's a lot better than IP addresses.

Lastly, if you still want to go with storing IP addresses, there are basically two ways:

Bloom filter, as mentioned before. This is not 100% correct though, but probably good enough for this purpose.
Using a hashing function which takes forever to compute. Sha-2'ing the IP a couple million times, it's impractical to brute-force it.

(There are about 3.7 billion globally usable and unique IP addresses, so if it takes 50ms to compute one hash, it takes 2.9 years before you have 50% chance of brute-forcing one of them, not taking Moore's law into account.)


Is it possible to decrypt a satellite TV signal without using a smart card?

A satellite TV system must face the following challenge: it is one-way. The receivers cannot do anything but receive; they cannot emit anything.

The generic problem is known as broadcast encryption. In practice, things go that way:

Each subscriber has a smartcard, and that card contains a key Ks specific to that subscriber.
The media stream is encrypted with a key K. That key is updated regularly.
Along with the media stream, the publisher sends K encrypted with each Ks in circulation. That is, every minute or so, thousands of small blobs are sent in some "holes" in the data stream (apparently there is sufficiently free bandwidth for that); all these blobs contain K, but encrypted with the key of a subscriber.

Thus, a given decoder will just wait for the blob which contains K encrypted with his card-specific key Ks, and use the card to obtain K and decrypt the stream.

When a subscriber is no longer a subscriber (he ceased to pay), the publisher simply stops sending the blob containing K encrypted with the corresponding Ks. The next time K is updated (it happens several times per day), the ex-subscriber is "kicked out".

In older times, media publishers had the habit of doing everything "their way", which means that they designed their own encryption algorithms, and they were very proud of them, and kept them secret. Of course, such secrets were never maintained for long because reverse engineering works well; and, inevitably, these homemade encryption algorithms almost invariably turned out to be pathetically weak and breakable.

Nowadays, the publishers have begun to learn, and they use proper encryption. In such a situation, the only recourse for attackers is to clone smartcards, i.e. break their way through the shielding of a legally obtained smartcard, to get the Ks of that card. Breaking through a smartcard is expensive, but not infeasible, at least for the kind of smartcard that are commonly used for such things; it requires a high-precision laser and an electronic microscope, and is rumoured to cost "a few thousands of dollars" for each break-in. Attackers do just that.

Publishers react in the following way: with traditional police methods. The cloning method is worth the effort only if thousands of clones can be sold, as part of some underground market. Inspectors just masquerade as buyers, obtain a clone, see what card identity the clone is assuming, and deactivate the corresponding subscriber identity on the publisher side, evicting all clones of that card in one stroke.

From what I have seen, the break-clone-sell-detect-deactivate cycle takes about two weeks. It is more-or-less an equilibrium: the non-subscribers who accept the semi-regular breakage of connectivity are in sufficient numbers to maintain professional pirates, but they are not numerous enough to really endanger the publishers' business model.

We may note that Blu-ray discs are a much more challenging model, because readers can be off-line and must still work; and though each Blu-ray reader embeds its own reader-specific key, there is not enough room on a Blu-ray disc to include "encrypted blobs" for all readers in circulation. They use a much more advanced algorithm called AACS. However, for satellite TV, the simple method described above works well.


Why don't terminal IDs prevent unauthorized entery?

Yes, I believe the terminal ID refers to a username/password, and yes it is rather ambiguous.

I think the idea it is trying to convey is that log in credentials prevent user operational access to a computer system, but do not actually prevent access to the computer itself.

Its easy to argue that TV monitors do not prevent unauthorized people from entering a computer center, and possible to argue that a "Terminal ID" could be used to verify a person before allowing phsical access. The word "Terminal" though almost universally means at least a screen with a fully fledged keyboard, as opposed to a keypad next to a locked door - and this is the only reason I would say that B is the most correct answer.

I say most correct because to me your answer is also a degree of correct. As is ID badges really. It's a poorly worded question with even poorer options to choose from.


When a browser extension or user script pulls a JS file from Google's CDN, how does this compromise the user's privacy in terms of Google's reach?

jquery is just a library that makes using JavaScript a thousand times more easy. If google were to manipulate jquery to do some shady stuff people would notice but it is definitely possible. There's also the risk of DNS poisoning where an attacker will make your machine believe googleapis.com is at the attackers ip address and serve you their own version.

With that said, why do you need to use googles CDN at all? You could just get jQuery put it on the local machine and reference that. In the end however if you want to be anonymous with TOR turn off javascript, flash, java, shockwave and any of that other crap. They are all vectors that can be used to identify you. You can add an extra layer by using a VPN service so if they did get an IP address it wouldn't be your home IP address.


Is it safe to store a JWT in sessionStorage?

How bizarre! I asked basically the same question about a month ago.

In the end, we decided that using localstorage for the JWT token was ok, as long as we also did the following on the HTTP level:

Ensure the entire site was served over HTTPS
Ensure the use of HSTS
Ensure that, once live, only the actual redirect URL was included in the Auth0 rules, as well as our source code

We use the Angular CLI. It turns out that, despite the tree shaking provided by WebPack, unused variables still show up in the compiled source code, for example localhost:4200
Make sure that there are no localhost URl's actually on Auth0 (on the allowed redirect page, for your client). Make a seperate Auth0 account for testing

Add the X-Frame-Options header to every HTTP response, and set it to Deny
Set X-XSS-Protection to 1
Set X-Content-Type-Options to nosniff
Make sure Content-Security-Policy is restricted to your own domain name, and any CDN's you may be pulling scripts in from
Set Referrer-Policy to same-origin
Limit the JWT expiry on Auth0 to 1 hour

The above will give you an A/A+ on securityheaders.io, and will prevent the most common attacks (somebody embedding your website in an iframe, and extracting data from localstorage, for example).


Web clients have the right to pass any User-Agent string they like. There is no good reason to deny access just because your NIPS can not make sense of the user-agent string. If you let it do that, then you might deny access from legitimate users with non-mainstream browser configurations.

I would recommend you to configure your NIPS to stop blocking these requests, unless it can find something which is actually fishy about them. Something actually fishy could be if the string contains an attempt to do a SQL injection or XSS injection (hoping that the user-agents gets stored in a database and/or displayed in a web interface and those do not sanitize their input properly).


If you believe Apple, FaceTime traffic is end-to-end encrypted using AES-256. This is secure, in the sense that somebody intercepting the traffic can not decrypt it (as far as is publicly known).

However, crypto is hard and the security could be compromised if Apple has made an implementation error. I.e. because of a programming bug the traffic may not get encrypted correctly. Apple has previously shown that they made pretty secure systems (e.g. the iPhone in the FBI case), so this is not likely.

Even if the traffic is encrypted, the system is not secure without authentication. If you set up a connection to the wrong person, an encrypted connection is not going to help. In that case you may tell your secrets to somebody pretending to be someone else. Of course in the case of FaceTime it would be pretty hard to impersonate someone, because you can see their face and hear their voice. Verifying that you are talking to the right person is pretty easy, even though there is no technical solution for this in FaceTime.


What is your way to create good passwords that can actually be remembered?

This XKCD comic describes a way to generate a good password. The quality of such passphrases has been discussed in : XKCD #936: Short complex password, or long dictionary passphrase?


Emergency method to erase all data off a machine within seconds

Thermite.
Thermite burns at a temperature of thousands of degrees centigrade, which would be more than sufficient to destroy all the data stored in any modern data storage medium. It is also already used by militaries for the targeted destruction of equipment. Additionally, according to Wikipedia:

For example, thermite can be used for the emergency destruction of cryptographic equipment when there is a danger that it might be captured by enemy troops.


Segregation of Duties of 3 tier Applications

This is not something out of the ordinary but you need to keep in mind that, ITIL is not a set of rules but guidelines. It is upto each organization employing ITIL guidance, to set up their own interpretation of these guidelines.

And it is not unusual, although unfortunate, to have application admins messing up a procedure and handing it to the less knowledgeable personnel as gospel and watch them fail. Sometimes, again unfortunately, some of this effort is concerted, especially if the segregation of duties are fresh and they are resenting their privileges being stripped off of them.

Unfortunately there is no solution or explanation to the security rules in an environment, handling sensitive data. The best method I cam to realize is NOT TO avoid the steering committee meetings and assert your views on the security matters. I personally fought tooth and nail when they wanted to strip my team from accessing root account. At every organization, one or two people should be carefully selected and be trusted with these elevated privileges. Security decisions made in vacuum by people who don't know what goes into those decision but only making them because the decisions will make them look good on paper, should be avoided at all costs. If this means killing a couple of hours of your already busy schedule, sitting in nonsense meetings, let it be.


Setting node.js TLS ciphers vs observed behavior

ECDSA?
No ECDSA cert installed or no ECDSA-scan support in the tool you used, maybe?
Check with another tool. Or by hand on the command line with the openssl s_client command.


Recovering encrypted SD card after Android Factory Reset

There seems to be some debate over whether or not the SD card can be encrypted; Android did not support external media encryption when it was introduced, and the current state of that feature seems to vary significantly between the various versions of Android.

The most authoritative source I can seem to find is from a forum post (the author may be a Google Software Engineer:

  2012/1/10 Marc Blank : The answer here is somewhat
  nuanced.  ActiveSync can require that the device and/or sd card be
  encrypted, and we enforce those policies in ICS; however, ICS does not
  have the ability to encrypt removable storage (i.e. SD cards). So
  here's what happens:

  1) In all current versions of ICS (up to 4.0.3), we accept the
  "encrypt device" requirement and reject the "encrypt sd card" in all
  cases (reject = we don't allow the account to be created/synced on
  device) 2) In the next update to ICS, we will also accept "encrypt sd
  card" if and only if the device is encrypted and it has no removable
  volumes (this is true of the Nexus S and Galaxy Nexus); on these
  devices, all internal storage is encrypted when device encryption is
  enabled.

  Having said that, the Email/Exchange application never stores emails
  other than in internal storage; however, user can still choose to save
  attachment files to "sd card" (which may or may not be external)
  unless, of course, the ActiveSync policies are set up to disallow
  loading of attachments.

  Does this make sense?  Sorry if it's complicated, but ... that's how
  it is!

  Marc

Having said that, in general I agree with the comment by Polynomial - it will probably be impossible to recover the contents of the SD card.


Does a VPN protect a network through which data is being transferred?

No.

A VPN provides an encrypted tunnel between an initial device A and a server B where the data is decrypted and processed, for example by forwarding onto a requested server C.  Responses from C are sent back to B, encrypted, and sent to A.  This means a man in the middle, M, can't determine what A is sending to C in a scenario where all of A's traffic goes through M.

HTTPS does something similar - A could talk to C directly, and M would only see encrypted traffic.  If C only serves data via an unencrypted connection however, such as HTTP, M would see all the raw data.  This latter scenario is what VPNs are useful for.

In any scenario though, B does not (ordinarily) do anything to the content sent back to A.  In this sense it's 'dumb'.  If the connection between A and C is ordinarily not encrypted, then B could potentially perform packet inspection and check for known exploit code etc., but in practice this is impractical most of the time.


Activating a user on a website -- why include anything other than an activation code?

Seems to be a poor practice. All they need is a unique activation code that maps to your new account.

Some of them (e.g. secret=) can be treated as ephemeral and hence don't increase the risk by much, but in general limiting the exposure to any information / internal structure is always a good idea (despite all arguments against security by obscurity) - especially when used along with other security measures. There is also the additional risk of additional potential injection points with every additional parameter.

All considered, it is not a practice that I'd recommend.


Is it dangerous for a scammer to know just your name and birthday?

It depends on what other information they have.  If it was in fact a scammer, they may have had other information but needed your birthday to make use of it.  In that case, you'd have an imminent risk of identity theft if they were able to capture the additional information needed to make use of what they already had.

That said, name and birthdate by itself isn't really a big risk.  I have my name, birthday, education, general area I live, e-mail address and home phone number all publicly listed on my website in easily scrapable fashion and have never had issues with identity theft.

Most of that information can be obtained online already anyway from a variety of open source sources, such as social media and public records as well as from database dumps of compromised corporate databases which most people are likely to have been in.

Certainly any expected fraudulent call is worth following up with the legitimate company to validate if it was real.  If it was a real call, you have nothing to worry about.  If it was not, then they will want to know so they can warn other customers if this kind of fraud is being targeted at many of their members.


Is it practical and/or secure to get my friends to remotely sign my OpenPGP public key?

There is no definition on how you have to verify identities for OpenPGP certifications. This is completely up to you -- some people define a certification policy because of this.

Whether to accept a video chat or not depends on the policy of the certifying side. I would still not expect an attacker being able to render photorealistic video footage in real-time; so embed the key exchange in a conversation, or include multiple persons and for example hand-writing the fingerprint while reading to a whiteboard. Additionally, the paper referenced used many hours of high quality video footage for training -- would you expect this to be available at all? Finally, is an attacker with such powerful computing resources and capabilities available that would risk being observed in such an attack?


JSON Web tokens claims. Where do I put a username

sub is just a predefined claim.

As stated in your link, this is for "interoperability". If you do not need to exchange your JWT with other systems, now or in the future then you can use private claims (e.g. name). If you are using sub then all systems that are receiving this token must interpret it the same (that is sub means username and nothing else).

Note that reserved claims are also stored within the payload.


Any one know about UDP traffic on source port 26221?

The source port is almost always randomized so this information does not help classify the type of traffic.   The packet's contents may contain identifying information or the destination port may help, for example destination port 53 is probably DNS.

WireShark is pretty good about identifying traffic, and I am pretty sure it doesn't look at the source or destination port numbers.


Internal HTTPS recommended security practices

Since everything is internal, the documentation seems to indicate I do not need to use SSL. Would there be any security risk to not using SSL for intranetwork HTTPS?

I would highly recommend to never assume anything and expect everything. I would suggest to contact the security officer or someone in charge for security. Security policies are often different between companies.
As far as is there is any security risk to not use TLS (Note: SSL is depricated), is the management of certificates in internal networks. In my experience, small to big networks have issues managing their certificates properly.
One concern is the availability, when a certificate expires a front-end machine can no longer communicate to a back-end machine for example.

Would that open the door to man in the middle or a spoofing attack?

By not using TLS internally it could be possible to perform a man in the middle attack and thus sniff specific traffic that is sent from your application to another. However, the company you work for could have accepted this risk and decided not to implement TLS on the internal network.

Further, what security "hygiene" would you recommend for this kind of setup? I.e. How often should the basic auth credentials be changed?

Personally, I would try to use TLS internally when sensitive (client) information is transmitted from one system to another.
Also, using basic authentication is something I (personally) would try to avoid because:

When using HTTP, the credentials can easily be sniffed. HTTPS would prevent this.
In each request sent to the web server, the credentials are sent. There is  no session, thus no timeout etc.
There is no 'real' logout function other than closing the web browser.

Are there any recommendations for reputably secure Python HTTPS packages for building out a simple server like this?

Perhaps not regarding Python packages but I would recommend to use a reverse proxy and not directly expose your web application to the internal network.


How should I block BIS connections from accessing my Exchange Server

The IP addresses for blocking BIS service are listed here (updated 11/10/11)

http://www.blackberry.com/btsc/KB11036

Preventing these IPs from accessing the OWA servers will prevent end users from bypassing security policy via BIS.


Is Java javax.servlet.http.HttpServletResponse sendRedirect() auto replace the carriage return(%0d%0a) to prevent Http Header Splitting attack?

Yes, GlassFish does filter newline characters in headers. Tomcat does as well. I don't know about other servlet containers (Jetty, WebSphere, etc.)

com.sun.net.httpserver does NOT filter newlines, so you can use that for your simulation.


Possible ways of exploiting PHP register_globals

To fix this specific vulnerability you need to call start_session()  before using a session variable. This way,  PHP will initiate $_SESSION and overwrite the injected values.  For the value$hidden_password,  this needs to initialized somewhere in the application and therefore cannot be controlled.

In general register_globals should be disabled!  It causes other security problems and will be removed from the language


Is there a risk in rebooting a smartphone while it's connected to an unknown USB port?

In addition to the risk of phone can be booted to ADB (Android Debug Bridge) or CLU (Command Line Utility) there is a bigger risk in connecting to unknown USB connections as follows:

USB is much more capable of being used to steal data, as it is already designed to transfer data as well as provide charge. When a mobile device connects to a USB port, it attempts what is known as a "handshake," at which time some data is transmitted. "Even when a mobile phone is in 'charging only' (locked) mode, it can still transmit the device name, vendor name and serial number to the system behind the USB port, and more based on the platform and operating system of the phone".

Source: https://www.techrepublic.com/article/free-charging-stations-can-hack-your-phone-heres-how-protect-yourself/

That’s why there are recommendations on not to use public charging points where the risk of being hacked is high. And it is not recommended to unlock and use the phone while charging, and to utilize proper encryption when possible.


Someone updated my friend's twitter profile after an internet forum abuse

I do not know of a way to retrieve who did this short of asking Twitter. As to prevention, demanding on availability you could tell your friend to enable 2 factor authentication
This will make any login attempt more noticeable due to getting a sms.

More about security on Twitter you can find on
Twitter Security Center

We can only guess what happened without twitters assistance. But a short list of possible attack vectors are

session hijacking / stealing
password / account guessing
xss attack

Most likely if she used a link on the forum it was a xss injection through a remote script.

Session hijack or stealing is likely if the forum itself was compromised (and added malicious scripts to the pages to enable this)

Password / Acount guessing is most likely in the other cases. (This includes brute force)


Are there any type safe languages with deterministic compilers?

There are tools to make builds deterministic. However it is not as simple as picking the correct language and compiler. You also have to eliminate all sources of non-determinism from the build. This mostly consists of time stamps and check sums. See https://reproducible-builds.org/docs/deterministic-build-systems/ for a more complete list of non-determinism.

Reproducible-Builds also lists several projects who use deterministic builds (https://reproducible-builds.org/who/). I noticed that a few used a combination of c or c++ and Gitian (https://github.com/devrandom/gitian-builder) using build scripts that strip non-determinism. For an example read the instructions for bitcoin core https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md.


Is there a good step by step troubleshooting resource to the common OpenVPN configuration error "TLS Error: TLS key negotiation failed"?

According to https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html, this message not only occurs if the key negotiation failed because of some crypto-related reasons or whatever, but also if getting any network connection to the other host failed.

Can you ping the other host and/or get a connection on any other port where a server is running?

Yes: All relevant firewalls need to allow connection on UDP 1194 too, eg. firewalls in network hardware and/or installed on your computer (eg. the Windows builtin one).
How it is configured depends very much on the used firewall.

No: Depending on your network structure, it may be necessary to add NAT port forwarding rules and/or static routes. Or maybe a cable is not plugged in...
In this case, it's necessary to get your network layout to tell you more.


What are the most challenging IT security certifications to obtain?


The Internet of Things is a pretty vague definition which covers an emerging collection of items that can be assigned an IP address and connected to the internet.

Typically, up to this point, the Internet has consisted of servers, routers to interconnect everything and endpoints such as computers, mobile devices, remote SCADA devices and other business related things you might want interconnected, etc.

The IoT just expands that to refrigerators, remote controlled beer kegs, flashing light displays, cameras and any old thing that you decide to concoct that you want remote access and/or control including your local nuclear plant.

The big issue is that things like remote WiFi connected Barbie Dolls have a certain price level that they can be produced at, and so as is often the case, all attention to security is thrown out the window as an excessive added cost. Something I might add, that you don't want happening when you've included internet connected industrial process control into the IoT.


If my antivirus caught suspicious .exe files transferring from a mac to my PC, am I safe from them?

No, .exe files are Windows specific (DOS, OpenVMS, Microsoft Windows, Symbian or OS/2) and do not run on MacOS, as the platform is not compatible with these.

When you do not execute them on your Windows PC you are safe, nothing happens until you manually execute them.

Antivirus solutions often work with hashes. An antivirus solution for MacOS can also often find malware and viruses for Windows as they share some hashes in their database.

Copying files does not execute them.


In return to libc how do you know the address of system() in a remote machine?

According to this reddit post. The following ways can be followed to obtain system() address on a remote machine for later return 2 libc exploitation.

No ASLR:
Find out their version of libc/msvcrt. It should (Windows makes no guarantees, Linux shared libraries don't either) be loaded at the same address every time. Find address of system, use it.
Partial-ASLR (no PIE):
The original binary will be loaded in the same place every time (again no guarantees on Windows). Find entry of libc/msvcrt function in the GOT/IAT, use that address.
Full-ASLR:
You need an information leak.


For servers that are not internet facing, do they need to be authenticated to each other and should their communication be over HTTPS?

It is easy enough to encrypt traffic and setup/maintain valid internal certificates that I  the pros are well worth the effort.  Encrypt your internal traffic.


Recognize site vulnerable for SQL injection

The fact that you can introduce parameters on the URL is not a vulnerability per se. (For example, I love imdb.com for the ability to control with those parameters)

The fact that the sql error is output to the user, AND the fact that the query is actually run against the database shows that the site might indeed be vulnerable to sql injection.

That simple statement is enough to show to your superior that something must be done. For better effect you might want to show a complete exploit case where you run successfully some query that you were not suppose to.


Encrypt data within mobile app and send to web service

You can't. This is a fundamental principle of general purpose computing.

You're running into Shannon's maxim:

  The enemy knows the system. One ought design systems under the assumption that the enemy will immediately gain full familiarity with them.

Just to make my point completely clear: you're giving someone a car, and asking them to only ever drive to one particular place. Nothing stops them from deciding to go somewhere else - you're relying on them adhering to your request.

If your security mechanism hinges on the hope that someone won't look at your executable and discover your encryption method / embedded keys, then it is not a security mechanism; it is an obscurity mechanism.

From what I can tell, you're trying to enforce that users are within a specified area via GPS coordinates, and also want to ensure that they don't spoof those coordinates. This cannot be done on a general purpose computing platform such as a smartphone. Let's look at the technology stack:

Your webapp sits in "the cloud" somewhere. You control this entirely.
Your app sits on a phone. You have minimal control over this, if any. Possible attack vectors include reverse engineering, app modification, direct webapp requests, memory editing, etc.
The smartphone OS (e.g. Android or iOS) runs on the device. You have no control over this. This is responsible for communicating with the GPS device and translating data into usable coordinates. Possible attack vectors include: fake GPS coordinates via test panel (most phones have this feature), modified GPS driver, hooked GPS APIs, etc.
The GPS module is inside the device. You have no control over this. The GPS module is responsible for communicating with GPS satellites and relaying the data to the CPU via a standard bus. Possible attack vectors include: man-in-the-middle on the bus, replacement fake GPS module, fake GPS satellite signal from software defined radio, etc.

So you cannot enforce that the GPS coordinates you receive into your webapp are correct, since they might have been tampered with at the app level, the OS level, the hardware level, or even the GPS signal level. Or, barring all that, someone might just skip the phone entirely and manually send requests to your webapp containing phony data!

The solution is to accept the risk or change your security model.


Possible vulnerabilities from letting users set session values manually?

The lang=us thingy isn't a session. The parts after the ? in an URL are what is called query parameters. As any other part of the URL, modifying them changes what page you get. That is normal and totally expected. It's no stranger than me being able to "manipulate" the content Google displays by changing whats after the q in https://google.com?q=test.

It seems like things you set the lang query parameter to is echoed back into the image src attribute, even if the value is not a valid language code. That is a bit sloppy, but it is not a security problem in and of itself.

However, if you do not do any cleaning of the query parameters before you echo them back into your HTML source you will be vulnerable to reflected cross site scripting (XSS) attacks. To know if the site you visited is vulnerable, you would need to do more tests.

To learn what a session actually is, check out this article. For information about how to secure them, read OWASP.


What's Google Inbox request/response obfuscation skill?

This object type is not readable for human.

Why should it? It is intended for a computer and not for a human.

  I've never seen this kind of security. Is this general dev stack? It looks very safe.

I doubt that this is primary a security feature. My guess is that they use some higher level development tool which just generates this kind of stuff. The aim is not to be readable by a human but to provide efficient processing by a machine - which often includes that it looks strange for humans. Such higher level tools not only speed up development but also often deal with the security problems better than handcrafted code.


Guidelines for secure iPhone application development

Here are five suggested guidelines for iPhone application development and security considerations. In general you'll find them to be the same as security for any application development.
http://intrepidusgroup.com/insight/2010/05/top-5-iphone-application-development-security-issues/


How is a random salt derived from output of password_hash(), given that hashing functions are deterministic?

password_hash and password_verify currently use either bcrypt or argon2 which both use the PHC string format. The salt is included in the hash format. It's not derived by password_verify, it's literally just right there in the hash you give it. This is not a weakness because a salt is not required to be secret, it must only be universally unique.

Your confusion about how password_verify obtains the salt seems to be caused by conflicting terminology. The word "hash" is often used to refer to the entire PHC format string (including the hash function identifier, parameters, salt, and actual hash value), as well as  the actual hash output by a hashing function.

See here for why salts are used. If you want a secret that an attacker would have to know to hash passwords, that's called a pepper.


Difference Between Web and Chain of Trust

The primary difference is that PGP does not trust a set of central authorities while SSL does. In SSL the certificate authorities do the required checks and then certify that the identity of the certificate holder is correct for the level of certification. We trust the CA's decisions and trust who they trust.

The different certificate types theoretically correspond to different levels of background checks. For a basic certificate this is as simple as verifying that the requester controls the domain. For an EV this requires significantly more checks (incorporation, place of business etc).


Effects of enabling/disabling location request on a browser

Location requesting involves using the geolocation API in JavaScript, and allows a website to obtain high-precision location information, usually by using the device's GPS and a combination of other sensors such as nearby Wi-Fi hotspots and cell towers. This allows websites to give you more relevant results based on your location. A hotel website might use that to automatically detect where you are and list nearby hotels. If you set your browser to deny location requests, it will simply not give your location to the website. The precision of the geolocation API can be very high, although accuracy varies.

Without location requesting, a website can still determine your approximate location based on your IP address. This is called GeoIP and cannot be avoided short of using a proxy to "change" the IP address you use. IP location info is generally very rough. Sometimes it can pinpoint the city block you live in, and other times it doesn't even get the city right. IP geolocation cannot be relied on for accuracy.

See also How does Google Maps know where I am, when I'm using a VPN?


Using cookies for cross domain authentication

Yes, there is a better option, and it's called OAuth.  It's specifically designed to support secure cross-domain authorization, and if you want more than bare authentication, there's a supporting standard called OpenID Connect that is built on top of the OAuth 2.0 framework that provides some richer standard data around users.


How to suspend a user from my website and prevent them from creating a second account?

There is no way to prevent multiple registrations.

I have two suggestions to offer

Make multiple registrations undesirable, for example by charging a fee.
Outsource the identity problem to someone else, for example my using Facebook or Google login instead of rolling your own.


Use Authentication using 2 encrypted strings

It sounds like you're trying to store an authenticatable message with a client. For that, you want to use an [HMAC]. Some of the downsides of this solution were recently discussed in the question Password reset links: random value or authenticated message?.

I personally lean toward databases in great part because you'll need to store something to be authenticated against at some point and database checks allow you to expire tokens. Once you pass an authenticated message, you can't kill it early unless you check a revocation list... database access again.


How do websites prevent certificate forgery?

The behaviour of HSTS is variable depending on whether the includeSubdomains directive is applied. In the case of HSTS without includeSubDomains, a user visiting www.facebook.com wouldn't protect them if they accidentally went to ww.facebook.com without an explicit HTTPS prefix. However, when the includeSubDomains directive is applied, visiting any subdomain (or the root domain) causes the HSTS rule to be applied across all subdomains. This can also be applied as part of preloading.

Pinning is a separate measure and can be achieved in a number of ways. The main two are preloaded pins in the browser (e.g. Chrome's pinning) and HTTP Public Key Pinning (HPKP). Another less-common way for pinning to be achieved is with a tool such as Microsoft EMET which adds additional pinning rules to the system. The goal of pinning is to store some identifier for the certificate (or its associated signing certificate) so that a false certificate from a compromised (or otherwise lax) certificate authority cannot be used to compromise communications.

In the case of preloaded pinning rules, the public key of the CA's root signing certificate or intermediate signing certificate is stored in the browser and the chain is verified when a certificate is presented for a matching domain. It is extremely rare to see leaf certificates (i.e. the actual specific certificate for the domain, rather than an intermediate or root certificate) in pinning rules due to the difficulty in maintaining this list when dynamic load balancing is in place.

In the case of HPKP, this feature works in a quite similar manner to that of HSTS. When a user visits the site, a header is returned which contains a list of hashes of public keys for valid certificates (either signing certs or the certs themselves). When the user revisits the site at a later date, the browser has cached this HPKP rule and can use it to verify that the newly presented certificate is still valid, and hasn't been spoofed either by self-signing or via a different (potentially compromised) CA. This feature also has the includeSubdomains directive, which can be applied to the HPKP header to state that all subdomains should be considered part of that rule. One additional feature of HPKP over in-browser pinning is that a "backup" signing key must be included as part of the HPKP rule, so that it can be used to update the HPKP rule if the original certificates expire.

With both of these features in place and the includeSubdomains directive applied to both, the following attack methods are mitigated:

Attackers who spoof DNS records to point to their IP cannot provide a self-signed certificate or any certificate with errors; browsers will not allow a click-through when the HSTS rule is in place, and the HPKP rule forces the certificate to match the given signing rules.
An attacker who compromises a CA, or who operates their own generally-trusted CA (e.g. nation states) cannot supplant the original certificate with their own, as HPKP forces a list of trusted CAs to be used.
Users who attempt to directly visit http:// are redirected by their client to https:// automatically; the browser will not communicate over plain HTTP with the server.
Attackers who spoof DNS records to a fake canonical name within the same root domain cannot spoof the certificate for this alternative subdomain; the includeSubdomains directive on each header causes all subdomains to be protected.


Why do KeePass dabases contain a hash of their master password?

The answer is in the the source code of keepass2john.c that you linked, from lines 156 to 163. The only hash included is the hash of the plaintext of the database. I let you read what the other fields represent, the source code is rather self explanatory.

TL;DR Keepass databases do not include the hash of the master password.


How to achieve interactive shell attack?

Graphical shells are heavy on the bandwidth, unreasonably complex, and usually unnecessary anyway. "Shell" in an exploitation context usually refers to a text-only shell; bash or sh or zsh for example. Or cmd.exe on windows. The idea is that if you can only run one command, then the one to run is a shell, bind STDIN/STDOUT to a network interface, and then connect to it with something like telnet. Then you can type whatever commands you want.


Secure a virtual machine during a lab exercise

It seems you have ignored the very best advice by cutting your citation just before it:

Kali users, please change the default root password!

If there's no known vulnerabilities in the Kali version you are using, it's relatively safe to use – unless you gave access to everyone by using default (or otherwise guessable) credentials. If someone gets into the Kali, it's possible to move laterally to every computer the Kali machine sees, and it also has all the tools required already installed.
So, securing your computer/network from the Offensive Security AWAE course VPN has two sides:

Securing your Kali Linux.

From the Kali's Default Credentials documentation you can see that:

Kali changed to a non-root user policy meaning the installation is asking to create a user with a password and sudo is used instead of the former root:toor default.
Pre-created VMware images use default user kali:kali which should be changed!
If you are using a Vagrant image, the default is vagrant:vagrant and should be changed!

Use strong passwords that can't be easily brute-forced.

Disable SSH logins and use the Kali from the VM console.

Securing your network from the Kali.

If possible, you could dedicate an old computer for your Kali. It's not necessary to use Kali in a VM, if you are afraid someone might break out from the VM and compromise the host.

Use the Kali machine (whether it's a VM or dedicated hardware) on an isolated network segment that won't see other devices on your network at all. Configuring the network like this is out of scope on Information Security SE.


I shouldn't really answer homework, but your upload script needs to have a very specific filename. Take a closer look at what happens if you upload a filename that already exists.


How is "hacking" even possible if I "defend" properly?

Not making sure all security updates are applied? Remember, as the defender, you must win 100% of the time. A hacker only needs to win once.

The steps you listed are also a lot easier said than done (except the password thing... and yet people still choose horrible passwords!).

2) Also, what's a "credible source" for a public facing web server? The entire Internet? The entire Internet, sans China/Russia (/some/other/countries)? Automated systems can detect many types of attacks, but just like antivirus they can only go so far.

3) Monitoring local files is good, but, again, it's not a panacea. What if the attacker manages to inject code into the web server, and then uses a kernel bug to get code into the kernel... without ever writing a file to the disk? At that point, they could write files to the disk, and use a root kit to prevent most (theoretically all) online scans from noticing any changes to the system.

And even if they only manage to exploit the web server, they can do everything the web server can do (which might be all the attacker was interested in anyways).

4) You should always validate user input. Most developers know this (and many try to do it). Sadly, it's much easier said than done, which is why we continue to see issue after issue where user input isn't appropriately validated. You'll never be able to guarantee any real piece of software is correctly validating all user input. Read some PHP+MySQL questions on StackOverflow to see how many people think mysqli_real_escape_string() prevents all SQL injection attacks ("where ID = " . $val is vulnerable, even when $val is the output of mysqli_real_escape_string!).

Even if you could (you can't) ensure every known attack vector was guarded against, you can't do anything more than wildly swinging in the dark against and unknown-unknown (well, continually educating yourself helps).

As an example where your defenses wouldn't have done anything, I was taking part in a security course where we're doing "war games". I was able to root an opposing team's server by being able to get one of their user passwords off another machine (one of them screwed up and typed it into bash as a command by mistake, and they never thought to delete it from .bash_history).

From there, I spoofed the IP of the machine they usually logged in from, and SSHed in, inputting their username + password. I had limited access to the system. I then ran sudo vim, entered the same password again, and had vim spawn a bash shell. Tada! Root access, from a credible source, without modifying any local files in an unusual way, without exploiting a weak password (it was bad, but even the best password in the world wouldn't have helped), nor relying on unvalidated user input.

At that point, being mischievous me, I manually modified all the log files related to my legitimate login, and obliterated their IDS (I'm betting they won't be observant enough to notice I replaced all of its binaries with copies of /bin/true!). A 'real' hacker would likely be far better equipped to ensure their activity wasn't detected by more vigilant admins, but I'd already accomplished my goal, and a small part of me wanted them to find out that someone got it.


Possible to safely send money via Paypal on public wifi networks?

Paypal transactions are already secured using SSL/TLS.

Assuming that you are using your own device that has not been compromised with malware, it should be perfectly secure to peform Paypal transactions on a public wifi network.


The router cannot open ports in your computer since the OS is the only responsible to manage it. A software firewall can mitigate some risks, however you are still exposed to the following when connecting to an unknown network:

All traffic not encrypted can be easily sniffed
You are exposed to DNS related attacks being redirected to malicious websites
Man in the middle attacks as well as session hijacking are way easier to be performed
Your computer may become a victim of scans to identify open ports, operating systems and supported protocols which your firewall is not protecting. After that the attacker can try to exploit possible vulnerabilities such as installing back doors. Then even disconnecting from that network won't help you anymore...


MD5 is not an encryption algorithm. It is a hash algorithm. Hash algorithm are one-way. There is no decryptor.

Hashes are used to generate a fingerprint of a text string. Reverse-engineering the input from the hash should be impossible. When the hash-function is cryptographically secure, there should be no way which is more efficient than trying out all possible inputs until you find one which coincidally has the same hash.

How do you apply this in a password system?

When the user tells you their password during registration, you don't save it. You generate the hash of the password, save the hash in the database, and forget that you ever saw the cleartext password. When a user then tries to login, they give you a password. You generate the hash of that password, and when it matches the hash in your database, you let them in.

But please note that MD5 is no longer a good choice for password encryption.

MD5 is a fast algorithm. At first glance this seems like an advantage because it makes authentication faster. But it also makes it much easier for anyone with access to the hash to try out passwords until they found one which matches.
The security of MD5 is disputed. Many flaws were discovered in the algorithm which make it possible to reverse-engineer the input of an MD5 hash in some scenarios.

For these reasons, you should use another algorithm when possible. A good choice for password encryption is bcrypt, because it was designed especially for this purpose. When an implementation is not readily available for your development framework, SHA-2 can be considered an alternative where implementations are easier to come by. It's not considerably slower than MD5 which makes it easier to crack given enough computing-power, but it has no known critically vulnerabilities like MD5. For low-security systems it's still adequate.


...does storing ciphertext in a database gain you much over using the database's built-in encryption?
I would think it protect data that was obtained from SQL injection or database access as long as the key remained safe?

No.
SQLi can be used to quickly escalate access to the rest of the machine.
Form the pgcrypto docs you list:

F.25.6.3. Security Limitations
All pgcrypto functions run inside the database server. That means that
all the data and passwords move between pgcrypto and client
applications in clear text. Thus you must [either]:
-Connect locally or use SSL connections.

-Trust both system and database administrator.

If you cannot, then better do crypto inside client application.

This means that if an attacker can get into the machine, your data is exposed.
As they suggest, if this can not be ruled out you can do one of two things:

Move the application to a separate machine so the key is not on the same machine as the database
Encrypt the data in the client application.

The ciphertext downside being you lose the ability to query the data.

Not entirely. Here is a guide on indexing encrypted data in SQL


MQTT without TLS - prevent publish messages from unauthenticated devices

As far as I know the first operation that needs to do after the TCP handshake is a CONNECT. So in theory nobody can send a PUBLISH message on the first MQTT pdu. But I will be worried if the implementation of your devices allows to receive messages without a CONNECT message. So it would be a good idea to verify if the implementation on your devices respect the order, first a CONNECT, by using a library that verify your concerns.


Password reset giving clues of possible valid email addresses

Don't indicate that the attempt "failed". A user (legitimate or otherwise), asks for a password reset link, and gives you an email address. All you should say here is along the lines of

  Your submissions has been received. If we have an account matching your email address, you will receive an email with a link to reset your password.

The user will still get the link (success), but attackers won't know whether a provided email address is associated with an account.


should one use "framekiller" code avoid others embedding https pages in iframes?

Generally it's always worth having, or rather it doesn't hurt and can prevent clickjacking attacks.

Of course it does depend on your usage scenario though. For example if the content you are creating needs to be displayed in an iframe (perhaps an advertising network) then you probably don't want to break out of the frame.

A good resource to read on the various approaches to implementing this can be found here.

One other thing to bear in mind that it can give a false sense of security somewhat, it's a bit of a cat and mouse game with regards to clickjacking attacks and defensive measures. Adding well implemented clickjacking protection to your site is great and definitely worth doing, but you'll need to review it periodically to ensure that it's still fit for purpose, like everything else when it comes to security :)

EDIT

Just wanted to clarify that clickjacking defense should include both X-Frame-Options and a bit of javascript for older browsers which do not support X-Frame-Options headers. The javascript layer of the defense has several limitations though which are also disccused on this page.


Risks of giving a hacker my WPA key for my router?

If the attacker is sufficiently close to the access point and can connect to it, he can view all unencrypted network traffic that goes past your router by using a packet capture utility like Wireshark. Although WEP adds a slight barrier, its still easily decipherable even by unauthenticated users.

On a side note: WEP has been shown to be completely broken. Any attacker close enough to your WEP secured access point can extract the key just by packet captures - typically within minutes (without any social engineering). Thats why its important to use at least WPA2 to secure your network.

To answer your other question: Once the attacker is on your network, he can launch a brute force attack on the router login credentials (no such attack needed if your router uses default authentication credentials - a comprehensive list of default router passwords can be found here). Once successful, he has effectively "owned" your router and can even lock you out by changing the password. A comprehensive list of attacks on wireless networks and their users can be found here


Looking for open source crawler/spider & scanner

Wapiti (python) and Skipfish (C/C++) are both good open source scanners that are not bad.   My biggest complaint is that they are overly simplistic,  for instance Skipfish doesn't actually have an html parser,  instead it uses a system of overly simplistic regular expressions.  Wapiti uses Python's html parser,  which is better,  however Wapiti isn't actively maintained.   Skipfish's biggest problem is that it will DoS web application with the traffic it produces,  so I wouldn't run it on a production system.

I studied both of these projects when building my scanner Sitewatch,  we provide a free service and its better than any open source web application scanner I am aware of.


Do people even exist who actually vet all the updates to their open source software?

Reviewing diffs between versions of open-source libraries and packages seems very excessive to me. The amount of time that it takes to do it, along with the necessary knowledge of the architecture and implementation details of the project make it seem very limited in utility. The general idea of vetting external software isn't. Various organizations that I've worked with have had different policies or expectations for how to handle third-party dependencies.
Some of the strategies that I've seen, used in various combinations, include:

Regular risk assessments. For commercial products, this would be a vendor assessment. For open-source products, evaluating the release cycle, testing, issue tracking, maintenance, and support for the product against needs. A component that doesn't meet needs can be scheduled for replacement based on risk.
Static analysis of open-source software components. Some vendors offer free scanning for open-source projects, so it could be a review of that report. It could also be using the organization's static analysis tools to scan the included open-source libraries.
Software composition analysis to track the versions of third-party dependencies and monitor for reported vulnerabilities.
System-wide scanning and testing. If the third-party dependency has a vulnerability that is exploitability, it may be detected when testing the entire system.


When and how will Internet Explorer refuse sha-1 certificates?

Microsoft announced a SHA-1 notice for their browsers starting in June 2016. The wording of the notice is still "under consideration".

  December, 2015 update: Microsoft is aware of recent advances in
  attacks on the SHA-1 algorithm   and we are evaluating the impact of
  moving the dates on our schedule up further to help protect customers.
  The most significant revision we are considering is to introduce a
  "speed bump" into the process in June of 2016, which will provide a
  notice to customers that the website is using a SHA-1 certificate. The
  exact wording of this prompt is still under consideration.

blog entry by Kyle Pflug, Program Manager Microsoft Edge

TechNet article on Windows Enforcement of Authenticode Code Signing and Timestamping


While I'm an not a PCI auditor, that seems reasonable to me.  I'm not sure that it matters though, because good sense dictates that if Azure resources are part of your production environment, and particularly if they're storing sensitive data such as card data or PII, portal access should be protected with MFA. I would say this is a decision you make based on the fact that it's clearly the correct thing to do, and if it turns out to be important for your PCI certification, then you're already set.

Additionally, if it's helpful, Microsoft publishes an Azure PCI DSS Reponsiblity Matrix that can help you better understand what Azure resources provide in terms of PCI compliance, and which responsibilities are still yours.


Most companies have lists of VPN IP's and will block them to prevent users from outside the country to use their services. So they probably can't "see" you are using a VPN, but the recognize the IP and block that.


Humans are rather terrible at generating random data. Ask a person to give you a random number between 1 and 20 one will get a lot more 7's and 17's than other numbers as we perceive those numbers to be more "random". (Source: http://scienceblogs.com/cognitivedaily/2007/02/05/is-17-the-most-random-number/)

Computers on the other hand are deterministic and as such cannot generate true random data on their own. So pseudorandom generators are used which are slightly complex equations. Those equations need a seed which should be somewhat random. To generate this seed here are some methods:

High resolution of time measurement (often clock cycles) at the time of execution
User input, often from the mice, good implementations use the human inability to perfectly control the mice
External randomness generator, there are external devices that use some not deterministic chemical or physical process or some environmental parameters that fluctuate a lot to generate random data.

So to answer your questions.

  Does adding a random character to a pseudo-randomly generated password improve entropy significantly?

Adding characters to a password even when not perfectly uniformly distributed increases entropy. Is it significant? This mostly depends on the length the password already had, see Anonymous Coward's comment on this answer for an explanation.

  Does this mean password generators, such as the one built into Keepass, suck?

This completely depends on the way the seed gets generated. I do not know how Keepass does this but there are definitely password generators that use very good seed generation methods (sometimes combinations of methods).

  would it help for the user to manually enter a character or two in the generated password?

Assuming the resulting password stays the same length then it depends from your vantage point. As I said humans are very bad randomness generators and as a result this would theoretically reduce the entropy of the password. However it does add more variables to the password generation process which if correctly implemented could increase the strength of the password against attacks directed at the pseudorandom algorithm and seed process.

Edit: reply to comment

  How could a human adding 1 or 2 random characters (in a random position of the existing password) decrease entropy?

I'll assume you mean replacing 1 or 2 random characters as like I explained above, in answering the title question, just adding random (even if not uniformly distributed) characters will always increase entropy.

So let's look again at the process of generating the random data:

obtain a seed
use the seed as an input to the pseudorandom generator
obtain output from the pseudorandom generator (and use it somewhere)
use the output as the next input to the pseudorandom generator (this is most often done behind the screens of the pseudorandom generator)
repeat from step 3

A rather simple process and as a computer is deterministic the only unknowns to some attacker are the seed and the number of times the process is iterated before the output is used for the specific password we are trying to breach.

If one looks at this process one could wonder why not always calculate a seed and use that as random data, in the end the seed is what makes the process random. So what is the job of the pseudorandom generator? It's function is twofold, first of it allows multiple random data to be generated from one seed. This is important as good seeds are expensive. Next and maybe more importantly it creates uniformly distributed random data. And this is very important as the seed (say when we are using some time measurement) will often have some structure.

Now when you replace 2 characters of this uniformly distributed random data with less uniformly distributed random data (remember the 7's and 17's) then you are reducing the entropy of the password. However this does not necessarily mean the password is therefor harder to break, as it creates an extra unknown to the system next to the seed en # of iterations.

However as a side-note from a theoretical standpoint one could use those 2 characters of user input to help create the seed which could increase entropy in the system, depending on the previous seed method and what else is used to create the seed.


Although I am still interested in any additional information the community can provide I am happy to report that the issue has been mitigated through a client modification.

I'm using OpenSIPs 2.3 which provides TLS via a module tls_mgm. This module has a setting for handshake timeout which defaults to 30 although I am running with 60. The docs state that this value is in seconds however the developers have confirmed that in fact the value is in milliseconds.

Increasing this timeout to 500ms has stopped these issues. My use of a high strength cipher is likely responsible for the upstream device incurring a delay when calculating its handshake key so its reasonable for us to run at this value - you can't put a price on security!


Multiple Open ports on a server, is that safe?

There are a lot of misunderstandings and assumptions in your question, but I will try to address them.

First, you are scanning a domain (I assume from the Internet). Just because nmap shows them as open does not mean that they actually are. There are a lot of devices in between you and the domain that could be responding to the scan, and they might just be responding to anything you send them without actually having the service running.

Second, just having a service running is not bad. Having more services running than you need just opens you up to a greater range of threats for no reason, so the advice is to only expose the services you absolutely need.

Third, "is it possible to exploit these services behind open ports" is the wrong question. It's like asking if a door you are looking at across the street is unlocked or not. There is no way to tell just by knowing that there is a door. You need more info.


You can try using a pre-paid gift card for this purpose, but know in advance that it may not be effective.

The modus operandi of many credit card thieves is to burrow into a victim company's network, extract the track or card data until they have enough to sell, then put the entire set of stolen data on the black market all at once.  This database of stolen card data is called a "base" on the dark web, and the individual credit card information record is called a "track".  At that time, the clock starts ticking.

They can sell the whole base to a single customer, or sell them one track at a time from a web site.  Often, the data they sell comes with a guarantee that it'll work or you get a replacement track.  Some sites even have customer service chat rooms.

Of course once they start selling tracks, the credit card issuing banks begin their investigations.  They'll do things like correlate the stolen card data in order to trace them all back to the company or companies that were breached.  Once they've identified the companies and notified them, the victim companies scramble to find the malware and remove it; investigators then follow the evidence to figure out when the intruders first started stealing the data; then they produce a list of all potentially stolen credit card numbers and give it to the banks.  The issuing banks then notify their customers and disable the stolen card numbers.  At that time, the clock stops and all the tracks in that base from that victim company are now worthless.

In cases like this, once your stolen card has been used the thieves are likely already done attacking that victim company.  Therefore they won't be harvesting your honeypot card.


Can an ISP redirecting DNS traffic be detected by the end user?

There are actually numerous useful hits when searching for detect isp dns interception. It basically boils down to this:

Check if any target port 53 gets redirected:Use tools like dig or nslookup to use an arbitrary external IP address which likely has no DNS server running as a DNS server. If one gets a response something has intercepted port 53 and replied to it.
Check if port 53 to specific servers gets redirected:Do a UDP based traceroute against the intended DNS server at port 53 and some other port. If the results differ a lot (i.e. port 53 has a way shorter route or totally different route) then there is likely interception going on.

For more see also How can I check if my ISP is intercepting DNS queries sent to alternative DNS servers? and Is Your ISP Hijacking Your DNS Traffic?.

Note that none of these techniques detects silent sniffing by the ISP. Also, in theory the ISP could work around such detection by not redirecting the DNS request but instead capturing a DNS response and modifying the result in it. This again could be detected if the response received differs from an expected response.
DoH (DNS over HTTP) prevents both sniffing and modifications.


Why is there a "show password" functionality in some login forms?

The 'show password' option is a feature designed for better user experience. This started getting popular with the recent rise in numbers of mobile devices. The small on screen keyboards are notoriously difficult to type with, and when you are unable to see your input it can make it difficult to be sure the password was typed correctly.

I am not sure of any attacks that target readable password fields. In my opinion, if you have malware on your computer that can see your screen, then its quite probable they are capturing your keystrokes as well.

Is it a risk? Yes. This should never be the default behavior, but if a user feels they are comfortable displaying their password (secure in their physical envirioment), then I see no problem with this practice.

This is just my opinion, not a rule.


You need to make sure your capture card is capable of every flavor of signal modulation that the target devices can use. Your AWUS051NH is a a/b/g/n device. If your target AP and client (the devices whose traffic you want to capture) are 802.11a-, 802.11n-, or 802.11ac-capable devices, your a/b/g/n card won't be able to capture their traffic.

Even just looking for, say, "802.11ac" isn't enough, as there are variations of 802.11ac that not all devices support: 2, 3, 4 and more spatial streams; 80MHz, 80+80, and 160MHz-wide channels; MCS 8 and 9 (256-QAM), various channels that are legal/illegal in different countries, that equipment designed for different countries may or may not support, and more.

You must also make sure your capture device is positioned "in between" the target AP and the target client. That is, where it can receive transmissions from the target AP at least as well as the target client can, and where it can receive transmissions from the target client at least as well as the target AP can.

You also need to make sure your interface is in both monitor mode and promiscuous mode (those two settings can be orthogonal; don't assume that monitor mode implies promiscuous mode on your hardware/driver), but it sounds like you already took care of that.

Uncertain if this will help or is entirely correct but after some google searching this is what I arrived at.


Can live bootable usb be infected by malware on hard disk?

Correct. Any kind of malware can't be running if you boot from USB stick. Of course I suppose you are using different PC with different motherboard than that one the HDD was plugged to before. Moreover, I can hardly imagine it would run under linux if it is Windows mallware ;)

Edit:
what is strange to me, the error you've got when you tried to DD it under debian...


Can installing Snort make me vulnerable?

Any software you install on your machine that takes input from other machines you do not control makes you more vulnerable.

You must balance the additional risk you add by installing Snort against the costs of any treatment for that risk you might implement and the benefits of installing it.

We can't do that for you because we don't know your threat model or why you want to install Snort.


How do you build a secure web application that is also COPPA compliant?

I've seen a similar example implemented in a site with online coursed for students.

The parent would create a "parent account", pay for the course and then be able to create a "student account" for their kid. The kid would now have access to the courses for a certain period of time and the parent would be able to track his progress, see what videos he has been watching etc.

So I don't think you have to create a backdoor, just a new type of accounts, let's call it supervisor. If a child wants to register your site, his account should be created by the supervisor.

One way of obtaining parental consent is by using credit card information and maybe a small one time transaction(1$), just to check that the data is valid.


Is it possible to run shell code from programming language A in a script that is programmed in language B?

The quick answer to your confusing question is "yes".

Buffer overflow attacks take a few steps.  There's the delivery phase (delivering the vulnerability), exploit injection (gaining control of the Instruction Pointer), executing the exploit (getting the Instruction Pointer to run the attacker's code), and shell code (the payload the attacker wants to run.)

Delivering the exploit is utterly trivial.  Attackers write the delivery code in whatever language they are proficient in.  It doesn't matter what language the delivery code is written in, because the language simply has to be able to deliver specific byte values into the buffer at the point of the overflow.  Different languages have different ways of expressing byte values.  Many attacks these days are delivered in URLs, which are text strings that are perfectly capable of specifying exact byte values.  I've seen an attack delivered inside a barcode, which is clever, but still trivial.

The exploit injection step almost always utilizes the victim machine's binary machine language to exploit the vulnerability.  The attacker finds a way to get specific bytes loaded into the buffer at the right point, such that when the function containing the buffer returns, it loads the attacker's bytes into the Instruction Pointer instead of the bytes that are supposed to be there.

Once the attacker has control of the Instruction Pointer, the IP has to be set to point to the exploitation code, and execute it.  This can be easy, this can be difficult, or this can be virtually impossible.  It's all a part of analyzing the vulnerabilities to create a successful exploit.  The goal here is to get the victim machine to launch the shell code.

Once the exploit launches the attacker's shell code, the rest is history.  The shell code is specific to the machine it's being run on.  Most often, it's also in binary machine instructions that are hand written in assembler, because the original buffer being attacked usually has size constraints.  A buffer overflow vulnerability doesn't automatically mean an infinitely sized buffer is available for the attacker to deliver a large payload of shell code all at once.

Once the shell code is running, the attacker has pwned the machine, and can control it however he wants.  To start out he'll often have the shell code expose a native command shell present on the victim machine.  That could be bash, a Windows Command shell, PowerShell.  Other possibilities include downloading and running a malware agent; allowing for remotely managed operations.  Common names for these infected machines are "bots" or a "zombies".  These run in a custom command and control language designed for operating thousands of machines in a botnet.  Once the shell code is running, the attacker is free to download more code to carry out his malicious commands.

Notice that all the exploit languages are completely unrelated to the language the attack was originally delivered in.


Is plain text over https really a good idea?

Good ideas are time-bounded.

Protecting passwords by MD5'ing them was once a good idea. Then rainbow tables and MD5 collisions were discovered. So now it is a bad idea.

Sending plain-text passwords over HTTP is a very bad idea, sending plain-text passwords over HTTPS is a very good idea by comparison, but there are still better approaches you can take.

Memory - As a general guide, you must assume that the server you are sending your credentials to is secure, so don't worry too much about plaintext passwords being held in memory unless you're looking to develop ultra-secure applications.

Logs - Logs generally do not contain any HTTP POST/UPDATE data, because that data is potentially very sensitive - and sometimes to store it in unencrypted log files would be illegal - such as when a client submits credit card details for processing a payment.

Passwords should only be sent as part of the HTTP request body, never in the URL for the site, and preferably not in HTTP headers either. BASIC HTTP authentication uses a password field in the header, primitively protected with Base64 - but this is only to prevent people shoulder-surfing the password, it won't protect it from anything else.

You could look at Client Side Password Hashing, which would involve hashing the password on the client side before it is sent to the server - thus even the server would never have the real password text (and should still further salt and hash it anyway), but this is more complicated to setup and is not recommended for anyone who doesn't fully understand what they're doing.


probes for phpmyadmin setup scripts are really just a fact of life at the moment if you run a web facing web server.  I wouldn't assign too much significance to the locale that they come from .

As far as I'm aware it's just pretty much blind scanning looking for known vulnerable software.  I get it on a regular basis on my web server even though I don't (and never have) run phpmyadmin on it.

After ensuring that you're not running it on the host(s) in question I'd recommend just filtering it out of the alerts that you're getting.


Is there a service that checks PYPI packages?

If a package has been discovered to be malicious, it will be taken down. The npm advisories link for malicious npm packages is mostly a history if you're looking at packages to download. There isn't a need for a service to tell you whether a package you're about to download is malicious (because it would not exist).

On the other hand, when looking at currently installed packages, in npm, there's a built in feature, npm audit, which will tell you if the packages you're using have vulnerabilities (including known malicious packages). This is actually a newish feature, only released in the past year.

It appears this isn't built in to PIP, but there's a well known package called safety: https://pypi.org/project/safety/ that achieves the same functionality. It looks like this achieves your goals?


Using Diffie–Hellman key protocol to create a safe secret key

Diffie-Hellman allows two parties to generate a secret key which cannot be recovered by someone snooping on the communication. This secret key can be used to set up a secure channel between the two parties that ran the DH protocol.

The secret key is established between the two parties that exchanged the initial messages. If you send out one message and receive a response, you have no way to know that this message comes from your friend. It could come from a man-in-the-middle instead. A MitM can reply to your message and send a message to your friend, and thus set up one secret key to communicate with you and one to communicate with your friend. Form that point, both you and your friend have a secure channel with the MitM, who can choose to relay messages and snoop on them, or modify them, or withhold them, or inject messages as he wishes.

There is no way to set up a secure channel without authentication. If you want to be sure that you're communicating with your friend, then you need to know something about your friend before the protocol starts, so that you can tell your friend from an attacker. For example, you might have your friend's public key. Your friend faces the same problem.

Once each party knows the other's public key, DH is a possible way of establishing a secure channel. The DH setup messages are signed by the public key, so the receiving party can check their authenticity.


I say put up an IDS and/or enable firewall logging capable of detecting port scans.

Wait for one to happen naturally, and then show the client the evidence that they're already being port-scanned.

Alternately, you can simply schedule some downtime, unplug the WAN interface from the Internet, plug it into a standalone local router that pretends to be the Internet, and run the portscan; physically invisible from the Internet.


How to access Replay Protected Memory Block (RPMB) in eMMC?

RPMB can be used using mmc-utils.

It can withstand replay attacks by requiring a key to write to this region. The rpmb has a key that can be programmed once. Later, the host reads a counter value from the rpmb. It uses this counter value and the programmed key to generate a MAC. The device then checks the MAC given vs the MAC it calculated using the same key, and if it matches, write access is granted (reference, slide 4).


I think that is a false dichotomy, and your CSO is being plain silly.

Though I am fond of the silliness, the security department should be driving risk mitigation. Squabbling over areas of "responsibility" are obviously not productive, though it might fit into the general corporate culture.

While there are various ways of qualifying the realm of security and their responsibility - the CIA triad is one, but there are others - a mature, responsible CSO would at the least be pushing for a solution.

I have heard some say that the distinction between "security risk" and "operational risk" is whether there is a potential threat actor, or merely accidental or misuse.
While this does make a lot of sense, I think a more pragmatic approach would be to simply accept that there is substantial overlap between the two - and that just means there are more resources to work on the problem, not that everybody gets to abdicate responsibility.

That said - in this specific case, the process I would recommend is having the CSO (or technical people in his department) drive the mitigation procedure, define a framework for levels of risk, etc - and then hand it off to operations to implement a fitting solution. Perhaps the security folk can recommend a solution, or maybe they should just define metrics that the solution should meet, depending on how technical / hands-on the team is.

In this way, the company can handle the fact that while the risk is a security risk, the solution is an operational one.


How can Stolen Laptop tracking softwares survive OS reinstall?

Some software vendors partner with BIOS makers (e.g. Absolute) so that even if an operating system is re-installed, on network connection, the BIOS may be able to send back relevant information. Many of these products are gimmicky, for example LoJack can be blocked at a firewall/network level that will disallow it from phoning home.

These types of software are primarily aimed at someone needing low level security versus highly secured laptops/network/data whose attackers are determined threat actors. Meaning, they're aimed at someone likely to be exposed to say common theft (drug user, someone taking it to a pawnshop), versus someone on a state level who would likely remove the disk for data. (Remember data is worth a lot more than a laptop).

EDITED

I needed to expand on this a little on the downfalls of using applications like these. When applications like these DO detect the location of a laptop, the reality is, what can they do, and what are they determining for you? They will retrieve a network based location nothing more. They will not give you information on how to get the device back, so most offer a "wipe data now" feature, which works (again) for low level attackers. The reality is, they will return output to you stating: "Your machine is located on network 10.10.10.1" which means little given that any ISP will not give you information on say one of their users using DHCP on that network. For that you would need a court order.

Nowadays, you can modify Team Viewer to act as a similar "phone home" application if you modify your registry. In modifying your registry, you can remove the visuals showing Team Viewer from the toolbar, from the process manager, and so forth. Malware authors have taken to do this at times.


Why is a wildcard-subdomain callback URL in OAuth considered unsafe?

There are more reasons why this is unsafe:

OAuth can be redirected to any subdomain under wildcard potencial leak token and so on
Example: If you have just some subdomain and don't own the whole wildcard then the attacker can register other subdomain and make real good phishing attack like login page or serve malicious webpage
Each token issued this way will be cross wildcard origin (I don't know how many apps do you have under this wildcard)
If you have ssl just for some subdomain user wildcard the MitM attack is easy as I can redirect to non HTTPS web service of yours and obtain token and login as that user
Depending on OAuths providers implementation and yours if you have SSL for *.example.com the attacker can still use ..example.com to MitM attack the enduser as the DNS takes this but the. Sure if the OAuth doesn't validate if subdomain of subdomain

Related question: Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?


Why is there a preference towards long passphrases instead of increasing the hashing iterations?

Increasing the number of iterations makes the function more expensive to compute, both for the attacker (that's the point) but also for the defender. Thus, it feeds on the very scarce resource known as "user's patience"; the number of iteration cannot be made arbitrarily high. This is in particular true if one of the systems on which the password shall be hashed is under-powered (e.g. a cheap smartphone).

Using a more random password usually means using a longer password (the password is not made stronger through its length, but because of its randomness; however, you need more length to make room for extra randomness). A longer password implies extra typing efforts, so again user's patience is an issue, but at least this is an active user: human users are more tolerant of security procedures when they are doing something during the procedure.

Conceptually you need both a high number of iterations, and a strong password full of randomness. The randomness is what defeats the attacker; the iterations are there to counter the effects of Moore's law.


You can't. For example, if you call a printf() with a NULL as format string, you will get a segfault in the libc, although it won't be a libc error.

But you can be nearly sure, that the shared library doesn't checks some of the data structures it gets from the main program (or from another dlls). C libraries doesn't need to do that (normally).

And if something isn't checked against NULL-pointer dereference, probably it wasn't checked also against buffer overrun. And such errors are mostly caused be NULL-dereference. You should always check on the asm-level (even with the gdb), what caused the crash, and to make an assumption, what were it on the C level.


I'm not an expert, but I believe they say it might allow the VRAM to empty because typically volatile memory is erased when power is lost. To be sure the VRAM is clear, you'd want to turn off the PSU and press the power button to ensure no residual power is present in the system.

You ask, "How big of an issue is this vulnerability?" That depends entirely on who is using Tails, what they are using it for, and what other security controls they have in place. That said, this would be exploitable given physical access or arbitrary code execution, so it definitely is a vulnerability.

If you are running Tails in a VM, it will depend on the virtualization kernel whether the VRAM gets erased. Note that one exception would be if you pass through the GPU to the VM (ESXi does this quite well), in which case the VRAM will not be erased because the physical device is never powered off.


Is there any reason to use AesManaged over DPAPI in this scenario?

This is probably a little late but just as a recommendation for other people who stumble on this. For this type of problem I would always use ProtectedData over rolling your own implementation with AesManaged for two reasons. First, you don't need to deal with managing cryptographic keys with ProtectedData which is a hassle to do correctly. Second, there's a handful of security considerations that a developer needs to understand before hand-rolling their own crypto and even then there's a chance the developer could make a mistake and render the crypto useless. Why take the chance and risk a headache when a perfectly acceptable, already vetted, solution is already available?


Unless the spam is coming from the site you're visiting or that site already knows your email address, it's unlikely that site is to blame. In fact, unless you've associated your email address with some service that is a partner of the site you're visiting, there's no way for them to even get your address (i.e. whom did you actually tell your address to?).

Instead, a more likely scenario is a local compromise within your browser or otherwise on your machine or local network. Software running locally could scrape your address from forms you've filled out, and then could watch your activity no matter where you go or what you do -- no VPN or encryption or anonymizing service can offer any sort of protection if the attacker controls your computer.

Many people unwittingly install browser extensions; toolbars, "safe search" extensions, or other helpers as part of other software installs. The less scrupulous the software's distributor, the more likely these things get bundled in. Any such software could easily do this and much much worse.

Likewise, such software can be installed by infected websites using such vulnerabilities as the Adobe Flash zero-day vulnerability patched yesterday for Windows, OSX, and Linux. If you have Flash installed (and you likely do), then your browser was and probably still is vulnerable and being actively exploited by malicious websites.


There is no need to do full disk encryption in step 2. Simply do

dd if=/dev/zero of=/dev/sda bs=1M

where /dev/sda is the hard disk device (change it to whatever your disk is called). You might also want to change the block size.

If you don't like the overwrite by 0s (there are people who claim that such overwrites aren't enough to actually make the old values unrecoverable, though you need special hardware to recover the overwritten data), use /dev/urandom instead, for as many times as you deem secure. You can also use the program shred.

You could probably stop after step 2.

I'm not sure why you overwrite your RAID config block 3 times in step 3. If you overwrite the whole disk in step 2, it should already be gone. Also, AFAIK, it contains no sensitive information.

I'm also not sure about your step 4. Why do you think that this wipes the HPA? Shouldn't you do this before step 2, disable the HPA by making it 0 blocks long, and then overwrite it in step 2?

In step 6, you're scanning for bad sectors. You're not doing anything else. But since you're already scanning for them, you might as well use badblocks -w and do a destructive scan, which will overwrite every sector and make step 2 unnessecary.

Hard drives set aside a few sectors that can be swapped for defective sectors. These defective sectors are often still readable and they might contain sensitive information. So you should take care of those, too. They do not get overwritten in step 2 (nor, I think, in step 6)


In most cases doing an nmap -p 0-65535 -PN <ip> works well for testing a remote firewall's TCP rulesets.  If you want something more advanced you can use a packet crafter like hping which is designed to test firewall rulesets.  Here is some information on building packets with hping.


Using different algorithms to slow down GPU password cracking

Using a second layer of symmetric encryption prevents the secret data from being revealed if only a single layer is broken.
However, I don't think this is the smartest way to counter potential massive GPU brute-forcing attacks - what actually helps against them are three things:

use an encryption scheme that incorporates a key derivation function

the encryption should use a salt along the password. Chosing a salt value from a good PRNF with enough entropy or directly from a good hardware RNG is paramount.

ensure the password is recursivle hashed multiple times, as often as possible to not make the encryption scheme impossible. This considerably slows down brute force attacks.
PBKDF2 provides all of the above features, but scrypt (which I would recommend over the other if you are that concerned over the security of your data) adds the additional one:

the hash function used to derive the keys should be relatively efficient to execute on a general purpose computer, but difficult to execute on specialized hardware (ASIC) by using a serial, non-parallelizable hash function that needs a lot of RAM to work.

So, I would look out for a good (read: used by others already with good reviews) open/free source implementation of an encryption program using scrypt. AFAIR GnuPG only supports PBKDF2, which is pretty good, but not as good as scrypt, which is its main deficiency.


Node.js static file security: What happens if hackers can control my bucket?

If you lose controle over your javascript files. Anything can be done with them.
If you load the files inside your node application (Ea import them or eval them or such)
So A important question is why are you serving code from a different location outside of your controle?
Would it. It be better to serve data files from s3 and serve code from your own controlled host (Ea load in JSON files from s3)


How to find vulnerable sites on a web server

He uses cuteFtp Pro with password encryption so it's probably not FTP related.

sure? there are developer-targeting ftp-password-stealing malware outside that looks for ftp-credentails locally.

what do you mean by "infected"? malicious uploads? sql-injections?
who/how many devs have access to that server?

by that number of installations you must either be lucky or be able to identify the attack-vectors through log-correlation, but this needs some experience in doing so.

rule nr 1 if running internet-facing websites: be up-to-date with every deployed application and your server-os.


What precaustions should be taken when the file displayed by a webpage is specified by the GET value

You should be sure to put additional filtering on it to make sure it doesn't try things like that.  Personally, at a minimum, I would attempt to parse and reform the input and make sure that no operations like directory changes can occur.

A better option would be to store the filenames in a DB and pass in a simple token that could be used to look up the filename to use.  This could then be filtered for any input that doesn't fit what is needed for your tokens.  It also could allow your site to work without having to update the GET information unless you specifically want that for linking functionality.


What antivirus/internet security software now Kaspersky is off-limits?

The order to remove Kaspersky as a vendor only applies to government/DOD systems. You can use whatever solution you deem best for systems not under government control. Regardless of why you pick, realize that in making a choice you are trusting that vendor, and antivirus runs with admin privileges and can be a vector for attack.