Best way to securely send passwords from an application to a user operated server I have the following situation:

A user sets up a server that will have to receive login details.
Other users then create accounts and login to this server.

All  this happens only over LAN. I'm thinking of using HTTPS; however as the users will have to setup their own servers, they will not have signed certificates.

How do I make sure that the application is talking to the actual server without requiring (payed) certificates?

Or is there a better way to securely transfer these passwords?

You can use the Internet Protocol Security (IPSec). This way your LAN communications are both authenticated and encrypted for each IP packet of a communication session. It is not a problem whether your machines are running Windows or Linux based operating systems. Note that you can also use it in conjunction with Layer 2 Tunneling Protocol (L2TP) that interoperates perfectly with IPSec.


How can the content of a file refer to its own MD5? So I just saw this picture on Imgur:
http://imgur.com/gxRCrCM

The intriguing thing about it is that the picture refers to an old Daft Punk song named "Face 2 Face". The image's MD5 is 6b0cc07a5c4d3d8fface2face79d8205 which, amazingly enough, contains the phrase face2face in it.

How does one go about generating this type of hash? I always thought that one gets a totally different hash when even one byte of the message is modified.

What kind of computing power is required to perform this trick? Of course, I am assuming this is not a mere coincidence.

Also I'd love to know if there are other examples of such hashes, and what are some tools available for Linux or Windows?

'face2face' is only 9 characters, i.e. 36 bits since we are using hexadecimal encoding. It suffices to generate many pictures with some internal variations (subtle variations that do not impact the graphical output) and hash them all until the target string is obtained. Since we are looking for a 36-bit pattern and accept that pattern wherever it appears in the 32-character output (24 possible positions), then the average number of pictures to produce and hash will be about 236/24, i.e. about 2.8 billion. Since a basic desktop PC can compute several (many) million MD5 hashes per second, this should be done in less than an hour with some decently optimized code.

This has nothing to do with known weaknesses of MD5 with regards to collisions. The same could be done with SHA-1 or SHA-256.

This has already been discussed in this question.


Automating SSL login There is a HTTPS site which I need to visit really often. Unfortunately, the login window seems to be some sort of CSS popup which only opens after pressing a certain menu button on that site. That is probably why Chrome doesn't offer to save the username and password for this site. Hence, I'm always forced to re-enter the username and password which is really annoying because I need to visit this site very often.

So I'm looking for alternative solutions to this problem. Back in the old days, one could just look for the CGI or PHP script that managed login and then call the login script directly by pasting the appropriate URL in the browser like so

 http://www.example.com/cgi-bin/login.cgi?user=foo&pwd=bar

However, the site I want to be logged in automatically uses HTTPS and lots and lots of JavaScript and probably other modern technologies that I know nothing of. The HTML code has lots of references to external scripts and the JavaScript seems to have been obfuscated so I can't really find the code for the "Login" button without going to great pains.

That's why I'd like to ask this question before wasting lots of time for nothing. So can anybody tell me whether it is possible at all to find out what happens when the user presses the "Login" button and then emulate this by directly calling the respective script by pasting a URL into the browser? Or is such a thing no longer possible because of SSL?

In that case, is there any other way of automating the login process for this particular site or am I really forced to re-enter username and password every single time, which is really annoying?

There's no way to know without digging.  However, the SSL part doesn't really matter.  There are other issues that could make this impossible though.  To name just a couple:

If the login form is protected from CSRF attacks then you
specifically will not be able to paste a URL in your browser's
address bar and login.  CSRF protection stops that exact kind of
behavior
If the website uses a modern front-end app that communicates with the server exclusively via API calls, then a simple login wouldn't really do it anyway.  Rather, the login form is executing an API request to fetch authorization key of some kind, which is then stored in the front-end application.  As a result even if you could manually post to login form, that wouldn't do you any good.  Instead, the response has to be received by the front-end application to initialize itself.

That's just two off the top of my head.  In essence, there are definitely some cases where what you are trying to do will be impossible.  Whether or not that is the case for this particular instance is anyone's guess.


Reporting vulnerability to New York Times I have successfully discovered a vulnerability in the New York Times website. Is there any known way I can report this? I have not attacked it. But I found a bypass. What should I do?

They do not have a specific security contact listed, so you should email help@nytimes.com and ask for your message to be forwarded to their IT security department.


Can a structured (text) document be effectively encrypted My situation:

I want to encrypt an HTML document. My question is, if the following is known, is that going to weaken encryption?

It is a text-based document
It starts with <DOCTYPE HTML> or a few variants of
This is followed by an <HTML> tag, followed by a <HEAD> tag, which contains a number of '

Would this knowledge help a hacker to decrypt without the decrypt key? Would such knowledge make my documents effectively un-encryptable?

My apologies if this is a very simple question. I am a neophyte.

What you refer to is a known-plaintext attack where part of the original text is known to the attacker. While simple encryption schemes are known to be vulnerable against such attacks modern ciphers are considered to be safe against this. With these modern ciphers all the known-plaintext allows is to verify if the decrypted result matches the original input, but it is still a brute-force attack over all possible encryption keys needed since all possible  keys are equally probable.

In other words: it might be a problem if you run your own encryption. It is not a problem if you properly use established modern encryption.


Completely encrypting virtual machine (for free) I know in VMware workstation there's the option to encrypt a virtual machine. Is there a free way to do this without VMware workstation? I'm aiming for the fullest encryption and encapsulation possible (so full disk, but it would be nice to have temporary files created when executing the virtual machine encrypted too). The guest operating system would be Windows 7 and most likely Virtual Box would be used, but I'm open to other free alternatives. I was thinking of using TrueCrypt's full disk encryption but TrueCrypt is no long supported. The host operating system (is also) Windows 7.

It's not possible to encrypt the whole host machine.

You can not securely use encrypted virtual machines without full disk encryption on the host.

While the virtual machine is running, the host stores memory chunks, log data, configurations, and loads of other files on disk, leaving permanent forensic trail of a live decrypted virtual machine. File and project names will almost certainly be recoverable.

If you really have to, you can create a Truecrypt volume (it works fine on all Windows versions) and install VMware in it. The install would work only on the original computer you did the installation on.

If you are really paranoid, you can encrypt and external HDD with Truecrypt, and create a hidden partition it with VMware and virtual machines.
Don't write too much data in the original drive, as it would destroy the hidden partition, unless that was the intention ;)


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

Standard security advice is:

  Only download files from websites that you trust.

http://windows.microsoft.com/en-ca/windows/downloading-files-internet-faq

This implies that 1. we are active agents when downloading files from websites and 2. websites cannot download files to our computer without our interaction.

So, let's say I am using Firefox. I go to a sketchy website. Can that website download malicious content to my computer without my interaction or awareness?

Optional Context

I know that web browsers render content on my computer when I surf the web. In one sense then, they are always "downloading" stuff to my computer. Most of that stuff I don't consider to be a download, though. Even streaming videos, while they may cache content, are not downloads in this sense, and I assume these non-downloads do not pose a security threat.

By download, I am talking about what, by default, appears in the Downloads folder of my Windows computer. Usually, I have to click a download link, confirm that I want to save/open the file, and then watch the Firefox download progress. The downloaded file appears in my Downloads folder.

As such, I have given the download permission, I am aware as it is happening, and I can see evidence after it has happened, because it is in my Downloads folder. Further, I have to open the download before it runs. It's an interactive procedure.

Result: I feel safe on a sketchy website, if I do not initiate or accept any downloads. Am I misguided? Can downloads from websites happen without my interaction or awareness?

without my clicking a link on a website
without my giving permission to save/open the file
without the Firefox download progress indicator showing a download, and
without the download appearing in the Downloads folder.

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

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


I thought MDM software was meant to make smartphones more secure? From The Verge (March 2016):

  The new attack takes advantage of less rigorous software controls for corporate device users, particularly those who use Mobile Device Management solutions (or MDMs) to get apps delivered to their phones.

Granted this article is from 2016, but does MDM software installed on a smartphone make it more insecure?

The white paper provided has more details

  However, MDMs can also be exposed to Man-in-the-Middle (MitM) attacks. These attacks can allow
  easy installation of malicious enterprise apps over-the-air, because Apple gives apps installed
  using MDMs a free pass from heightened security measures.

and then later as they explain how the attack is levereged

  Wait for a command to be sent to an iOS device by an MDM: then, using a MitM attack, intercept
  and replace the command with a request to install a malicious app. The iOS device will fetch
  from the remote enterprise app server and install it.

The actual white paper doesn't go any further than "use MITM" and I'm very suspicious that this actually works due to the implementation of Apple's MDM protocol.

To understand why I highly doubt this attack actually works as described, you need to understand the crypto which runs the whole process. The gist of it is explained here by Apple:

  When the MDM payload is installed, the device initiates communication with the check-in server. The device validates the TLS certificate of the server, then uses the identity specified in its MDM payload as the client authentication certificate for the connection.

The check-in server referenced here is the MDM server. The important part to notice is that they'll need both a trusted certificate for the MDM server's domain and the cryptographic trust identity established between the device and the server during enrollment before they can impersonate and issue commands as the MDM server. Meaning if you wanted to impersonate the MDM server you'd need to hack their MDM server and steal the keys which is no longer an MITM and just a straight up attack.

I'm not sure what Checkpoint's game here is but their threat model is fundamentally broken and verging on a FUD campaign. They made mountains out of molehills (without even verifying that it's possible) because they found that an MDM server can make a device trust an enterprise signing certificate. This is the expected behavior! The point of an MDM server is to fully manage a device and that means it can add certificates to the system trust store and also forcibly proxy network traffic. This isn't a vulnerability, this is the intended behavior. Apple warns you about this when you're installing an MDM.

Checkpoint didn't find a vulnerability. If they cracked the MDM protocol's crypto then we'd have a HUGE problem on our hands and it would be worthy of a vulnerability name. I can fairly confidently say SideStepper is marketing bunk aimed at selling Checkpoint's security products.


Will checking origin and referer headers for CSRF protection block valid requests? If the origin and referer header check per the OWASP CSRF cheat sheet is followed, will valid requests be blocked (ignoring the token part of the recommendation for this question)? I've seen some references to the fact that such headers are not always sent so if requests are blocked if neither is present, then perhaps valid requests are being blocked. Is this considered a real issue?

Additional edit: The requests I am trying to check are only those that change the state (database) of the site. I would not allow $_GET requests to change the state. I would not apply the header check against $_GET requests that do not change the site.

This depends on what you consider valid requests. If you expect all requests to be caused by navigation inside your web application then it will work unless you explicitly request that the Referer does not get send or if the user uses some kind of Referer blocking (browser extension or configuration). But, if you consider requests valid which come from accessing a bookmark in the browser or a link inside a mail then these will cause problems because no Referer or Origin will be sent.

EDIT: since according to the updated question your application does not expect GET requests to be state changing and thus you don't check these for CSRF bookmarks and links inside a mail should not be a problem and thus you can expect the Referer and/or Origin to be sent with each state changing request.


Temporarily blocking too many login requests for only the targeted accounts When temporarily blocking a client by IP address making to many login attempts, what are the security implications of only restricting them from attempting the same login email/username again for a short time?

This would severely limit the impact of a DoS attack, usually other machines on the same network also be limited, this method would only restrict access to the attempted accounts.

The implementation would have to restrict attempts even to user credentials not in your system to avoid user enumeration.

The secuirty measure would simply be a joke then and you would be litereally wasting space and code(if the attack is against a login such as spotify or something as large. A forum maybe?) People have became witty about how they conduct these attacks. Taking combinations of user:pass or email:pass and using these to login while using HTTP/HTTPS high level anonimity proxies. Also refered to as credential stuffing. This is a very effective attack method. As for targeting one user account. They better just have a lot of proxies and a script that identifys whether the proxy has been banned and uses a different one.


How to get my OpenPGP keys signed? I was wondering if anyone has any recommendations for getting my OpenPGP key signed by others. I live in the middle of nowhere, and there aren't meetup groups within 50 miles of me ever.

How to get my key signed by people, and how to meet people who use GnuPG and are trusted.

You Will Have to Travel

The short version of the answer is: you will very likely have to travel, the user base is not very large, especially not those forming the largest strongly connected component of the web of trust (ie., the network of people all being able to mutually find a trust path in the web of trust). Less than 100.000 people (as of 2017) form that group, don't expect many of those living by chance near you "in the middle of nowhere".

Subcommunities

When looking for certifications on your OpenPGP key, also consider what community of people you want to be trusted in. Just having "some certificates from trusted people" does not really help you at being trusted by all OpenPGP users, not even those being well connected. If you want to get a trusted identity in a given group, especially try to meet with people from that group. For example, meet Debian fellows for signing keys if Debian is (one of the) groups you want to participate and need a trusted identity in the OpenPGP web of trust therefor.

Keysigning Parties and Meeting People for Keysigning

If you are living in the "middle of nowhere", you will very likely have to get out of there. Attend meetings with key signing parties, expect such especially at free and open source software conferences. Again, if you for example want to get closer to the Debian community, join a Debian meetup. Chances are good you can find people for key signing there.

There is a (rather outdated and rarely used) directory of people willing to meet for key signing: http://www.biglumber.com/ (but experience shows that lots of entries are completely invalid by now, and only few actually respond).

Certificate Authorities

Finally, there are some "certificate authorities" (although OpenPGP does not really know this term): I know of CAcert which also signs OpenPGP keys (but again, you will likely have to travel to meet people to get CAcert-assured), the German Heise Verlag with its "Kryptokampagne" and if you have a German ID card, there is a service by Governikus that uses the electronic functions of the ID card to verify your identity.


How exploitable is the recent UseRoaming SSH vulnerability? I recently heard about a serious bug in an OpenSSH client (CVE-2016-0777 and CVE-2016-0778) that if I understood correctly could cause remote code execution. How difficult would be for an active man-in-the-middle to exploit that?

Like Steve Sether said, this is not a man-in-the-middle attack.

How dangerous is it?

In some cases, buffer overflow attacks are possible.
Your private SSH keys can be leaked to an attacker.

According to the page:

  SSH roaming enables a client, in case an SSH connection breaks
  unexpectedly, to resume it at a later time, provided the server also
  supports it. The OpenSSH server doesn't support roaming, but the OpenSSH client supports it (even though it's not documented) and it's enabled by
  default.

For starters, this feature is enabled by default in OpenSSH. Even worse, it is undocumented in the ssh_config(5) man page.

Note that this is two exploits:

CVE-2016-0777

An information leak (memory disclosure) can be exploited by a rogue
SSH server to trick a client into leaking sensitive data from the
client memory, including for example private keys.

CVE-2016-0778

A buffer overflow (leading to file descriptor leak), can also be
exploited by a rogue SSH server, but due to another bug in the code
is possibly not exploitable, and only under certain conditions (not
the default configuration), when using ProxyCommand, ForwardAgent or
ForwardX11.

Regarding the buffer overflow attack, note that it's only vulnerable under certain conditions, when you have ProxyCommand, and ForwardAgent or ForwardX11 enabled. Those are non-default options, so while it's possible it won't be exploited in a large majority of cases, it is possible.

In the case of a successful buffer overflow attack, assume everything accessible by the SSH client is breached.

More Information

I would read the Qualys Analysis. This paper will explain this attack in great detail far better than most of us, including myself.


Locking accounts using the same strong hash in the database A website has some bruteforce prevention for logins, and I need to turn that off because it's buggy and it's causing problems. It will stay turned off, probably forever, because there are no plans to do any maintenance on that website. It's a small company's website, there are only a few users (maybe about 10), and most of them (if not all) basically never log in. The last activity from the owner is probably from years ago. So yeah, it's pretty much half abandoned.
Now, if I just turn off the bruteforce prevention system, I am afraid I will potentially increase the risk of compromise, if any of the users happened to have weak passwords. I believe the risk will only increase slightly, because the system just bans the IP temporarily after a few failed attempts, so you still can get 10s or 100s attempts per day anyway, and if you really have a weak password I feel it won't help much. However I still feel that just turning off the bruteforce prevention system is not the right thing to do.
So I thought of this quick solution: disable the bruteforce prevention system, and change every password hash in the database with the same hash, calculated from a very strong password that I won't keep anywhere (create it and forget it). As a result, every user will have the same hash (same salt and same password) stored in the database. However, nobody can log in, because nobody knows the password (not even me) and the password is very strong. To log in, they will have to click on "I forgot my password" and create a new one. So I will just tell the company that the bruteforce prevention system has been disabled, but all their accounts have been "locked" to prevent increasing the risk in case some users are using weak passwords. If anybody wants to log in (to continue using their half abandoned website), they can click on "I forgot my password" and make sure the new password is strong enough (and I might give them tips or examples about what a strong password is).
Question: is anything wrong with my reasoning? Does this solution make sense? The only possible weak point I see is that I use the same hash for every user in the database (so every user will have the same salt and same password), because it's easier and faster to do so. However, I can't see how this weakness could be attacked, since the password won't be known or used by anybody, and it will be very strong (so bruteforcing the hash, even offline, should be out of the question). Am I missing anything?

This is fine. Practically, the chance that such random password was bruteforced would be zero.
However, the way to do this would usually be slightly different: rather than setting it to a valid hash, you set it to something invalid. I wouldn't be surprised if the password implementation was a custom one, so you should check what it is doing, but basically, if it checks that hash(salt, provided_password) == stored_hash you would set stored_hash to something like ! which won't be equal to any hash output.
This lets you perform the same without having that weakness. I would prefer this for being cleaner, as it more clearly separates the representation of accounts which are locked from those with real hashes.


Is the idea of a hosting provider with built-in DDoS protection plausible? Any PaaS/shared hosting company which I came across offers its customers to protect their websites from DDoS via security-oriented CDNs such as CloudFlare or CloudFront which act as a proxy distributing the content serving via various machines (instead just one machine - the one which hosts the website).
Is the idea of a hosting provider with built-in DDoS protection plausible? I mean, is the idea of a hosting provider doing the machine serving distribution by itself (without involving a third party) plausible?

It depends on what you mean by DDoS protection.
If you mean be able to serve normal request even when facing a DDoS attack using a very large number of relays, then the only way if to use a CDN that will be able to absorb the increased load.
If you mean to detect clients sending requests at an abnormal rate, and limit that rate, then a good proxy in front of the application server might do the job. If the number of relays is not too high, normal clients would notice a delay but the system would still be useable.
If you mean to protect the application and prevent it to crash because of the load, a good proxy is enough. It will limit the number of simultaneous requests, and the application will continue to work fine. Normal clients would notice that the system is hard to use or even unreachable during the attack, but everything will be fine as soon as the attack will stop.
Those last 2 ways are often combined on systems that (often for security reasons) do no want to rely on a third party service.


Why is privacy not one of the pillars of information security? We have the three pillars: confidentiality, integrity and availability.

Why is privacy not one of the three pillars?

Confidentiality is generally a privacy concern. It's just a more general term.

It's like saying animal instead of dog.

In addition to the definitions, you can confirm that by searching for synonyms of privacy and synonyms of confidentiality. You can use confidentiality instead of privacy, but not the opposite.


Could a neighbour see my traffic when we have cable Internet? Is it possible that a neighbour could see my traffic (*), when we both have cable Internet? Or: Under which conditions might this be possible?

I would assume, "Never!", but after reading these two answers, I’m unsure.

At the Server Fault question ISP broadcasting all IP-packets, so I can see traffic of other clients from ISP, closetnoc answered:

  For Cable, this is normal. Cable is segmented by neighborhoods depending upon area saturation. A neighborhood could be many miles or one block. This is normal since cable is not a frame connection but based upon broadcast standards much like ethernet over thin-net/thick-net back in the day. Your cable router may or may not enforce network segmentation depending upon the router, either by age or by model. Cable connections almost always see traffic on the WAN side that is not intended for the LAN. But sometimes WAN traffic can be seen on the LAN side. This is not unusual even today with the larger carriers.

At the question Does the method of Internet connection affect the security of your the network?, Tom Leek answered:

  In the "neighbour is the attacker" scenario, point-to-point mediums are also somewhat better than broadcast mediums; I know of some Cable providers where the cable is a thinly disguised carrier for ethernet frames, which are broadcasted throughout the building, the ISP "box" acting as a filter.

Am I misunderstanding something?

(* I’m not talking about a neighbour trying to sniff/decrypt my WLAN traffic, so assume that no WLAN is involved.)

There are different network types, but one of the most common is passively switched fiber to the street.  In other words, somewhere around 32 customers share a common fiber line from the ISP.  The signal from the ISP is passively split out to reach all 32 houses, so all data that is transmitted from the ISP can be received at each house.  Information sent from each house should only go directly to the ISP.

That said, a few different things can limit this behavior.  The cable modems are configured by the ISP to only pick up the traffic addressed to you.  Similarly, it is becoming increasingly common for encryption to additionally be used rather than a simple address for the filtering of traffic.  If your ISP has switched to using the encrypted system, then each customer's cable modem is the only one that can decode the communication sent to it.


Sharing RSA keys between PGP and SSH protocols: Does this pose a security risk? If I generate a PGP subkey that only has the authentication capablity and use this to generate an SSH keypair to authenticate Git for example, does this pose a security threat?

When I do, should I use my PGP private key, or the public authentification subkey?

Then when I add my passphrase-proteced private SSH key (./ssh/id_rsa) using te ssh-add command, I am prompted for my passphrase. But then when I make subsequent commits using Git, I am not prompted for my passphase by the SSH Agent. Why is this?

What's the best practice regarding this? Should I keep my keys seperate?

The problem is probably not so much algorithmic security. The problem is that if there is a security problem with one of the applications that you also have a security problem the other application. Furthermore, it may be that some kind of attacks on the protocol may be made possible because you share keys. In other words, this is not a good idea with regards to system security.

All in all, you should try to keep the keys separate. Usually one key is used for a particular application. Sharing encryption keys and authentication or signing keys may lead to attacks on the algorithm that would otherwise not be possible.

As for your second question, as long as the SSH session is authenticated the keys are not required any more.


Which grant type : Implicit or Auth code (with No secret key) is suitable for Single Page Application(SPA)? I went thru multiple posts saying how implicit grant is a security risk and why auth code grant with AJAX request to Authorization server should be used after redirecting to application (without client_secret passed to Auth server).

Now in 2019 there is no CORS issue as I can allow app domains on authrization server.

I have following concerns

If I use implicit grant:

Now implicit grant has security issues as Authorization server redirects to application server with token in url.
If I set expiration time to 5 to 10 minutes, after expiration, user will be redirected to login and its problematic especially if he is filling up important form on application. What to do in this scenario? Note that there is no refresh token in Implicit grant to update with new token, so refresh token is out of the picture.

If I use Auth code grant:
Suppose if I hit AJAX request after getting redirected to my main application site, and get token in exchange of code,

Auth code grant uses client_secret. And in javascript app where anyone can see the code, we cant use secret.

What approach should be taken here? I am more inclined towards auth_code for SPA but the issue is how to deal with client_secret?

Thank you for reading.

There are multiple links that recommends use Auth code grant instead of SPA. A few out of multiple links :

https://www.oauth.com/oauth2-servers/single-page-apps/

https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926

You don't need the client secret, you should use PKCE instead. There is a new IETF draft about best practices for SPAs


Can I crack a zip file using Hash Suite on Windows? I'm trying to crack a password I set on a zip file using Hash Suite but it doesn't seem to work for me (not sure if I'm doing everything correctly).

Basically, this is what I've done:

Created a text file, compressed it to a zip file with WinRar and set a password to it (pw: 123).
Opened Hash Suite -> Hash Calculator -> Hash a file, and I chose the zip file. The program now displays the hash in MD4, MD5, SHA1, SHA-2 256, SHA-2 512.
I save the MD5 hash in a text file, then import the text file into Hash Suite.
Lastly, I choose to start an attack in RAW-MD5 and the program runs for 1 minute.

I get not results whatsoever. Anyone knows the problem here?

You've calculated the MD5 of the file itself, not of its password ('123').

According to its download page, the only hashes supported by Hash Suite are as follows (and ZIP files are not included):

LM, NTLM, Raw-MD5, Raw-SHA1, Raw-SHA256, Raw-SHA512,
DCC, DCC2, SSHA, MD5CRYPT, BCRYPT, WPA-PSK

Compressed file formats are only supported for storing wordlists, not for attacking the hashes for those formats.

You can't crack a ZIP file with Hash Suite. (But you can crack some of them with its cousin, John the Ripper.)


Dangerous hardware ports? Using Passware Forensic Toolkit you can extract the bitlocker key using live memory dumping through Firewire (either by using an existing Firewire port, or by inserting an pcmcia/expresscard firewire card). No need to logon to Windows there...

Source: http://www.securityfocus.com/archive/88/516661/30/0/threaded

So OS independently Firewire is dangerous.

Are there any "ports" that could be dangerous? Why is Firewire dangerous? How could it be disabled? How to defend against: "or by inserting an pcmcia/expresscard firewire card"

There is some information and many pointers on this page. The common idea is that Firewire allows DMA: the plugged device can read and write physical memory at will (this allows fast data transfer without clogging the CPU; it is very useful for hard disks and fast network interfaces). For Firewire, some mitigation can be achieved by removing or nerfing the Firewire support on the OS (most Firewire controller require the OS to do a bit of initialization job, and we remove that part -- but there could exist Firewire controllers which will accept device-initiated DMA even if the OS does nothing, so it is hard to know if actual protection is achieved that way).

PCMCIA/PC Card/CardBus/ExpressCard are successive names for a peripheral standard which is, basically, a PCI (or PCI Express) bus with safe hotplug. DMA is consubstantial to PCI, so there is little defense against an attacker who has physical access to such a port.

Generally speaking, if the attacker can physically access the machine, you are doomed.


Hydra sometimes fails against my own router known password Hydra sometimes fails against my own router known password. Sometimes confirms it was found, and sometimes returns unusual error code (empty). What does this means?

dione@saturno:~/misc$ hydra -l admin -p myknownpass 192.168.1.1 http-get -vV

Hydra v8.0 (c) 2014 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2014-10-04 18:24:28
[WARNING] You must supply the web page as an additional option or via -m, default path set to /
[DATA] max 1 task per 1 server, overall 1 tasks, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking service http-get on port 80
[VERBOSE] Resolving addresses ... done
[ATTEMPT] target 192.168.1.1 - login "admin" - pass "myknownpass" - 1 of 1 [child 0]
[80][www] host: 192.168.1.1   login: admin   password: myknownpass
[STATUS] attack finished for 192.168.1.1 (waiting for children to complete tests)
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2014-10-04 18:24:29

dione@saturno:~/misc$ hydra -l admin -p myknownpass 192.168.1.1 http-get -vV

Hydra v8.0 (c) 2014 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2014-10-04 18:24:36
[WARNING] You must supply the web page as an additional option or via -m, default path set to /
[DATA] max 1 task per 1 server, overall 1 tasks, 1 login try (l:1/p:1), ~1 try per task
[DATA] attacking service http-get on port 80
[VERBOSE] Resolving addresses ... done
[ATTEMPT] target 192.168.1.1 - login "admin" - pass "myknownpass" - 1 of 1 [child 0]
[WARNING] Unusual return code:  for admin:myknownpass
[STATUS] attack finished for 192.168.1.1 (waiting for children to complete tests)
1 of 1 target completed, 0 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2014-10-04 18:24:36

Apparently, that router's web server is not very well implemented, and vanhauser updated his code in order to handle it.
This was my issue (now closed),

https://github.com/vanhauser-thc/thc-hydra/issues/18


Attempting to find a XSS, why doesn't this piece execute? I've seen these types of instances occur quite often, and I'm curious to why (even without a filter) they won't execute... as the code is right there. Every occurrence of this I've noticed that when you inspect in any developer tool the tags aren't formatted; so in a visual perspective, just gray text. I know it's a vague question with not much content/context, but in any sense how is a, seemingly, unfiltered place of input like this, not exploitable and rendered without a XSS issue?

Edit: I used Chrome (with XSS protection disabled), Firefox, and Internet Explorer (there's a warning message when it filter something it believes is cross site scripting). This obviously ended with no results or explanation.

This is the element example I gave when you follow it.

This doesn't have anything to do with XSS filters, as evidenced by the same behavior across many browsers. It's not a queryString thing, it's just content. The answer is simple and re-assuring.

Inline script tags added via .innerHTML=strHTML, or the DOM method elm.appendChild(script) don't execute. This means you can inject malicious tags in all day; unless such tags hit the browser as hard-coded HTML (can be seen in view-source), they are benign.

jQuery's over-used $(elm).html(strHTML) method WILL run scripts, but only because it parses the string content and sends <script> tag content to the window.eval() function, which executes it. By default though, dynamic script tag content is NOT executed.

Your example uses react, which has a virtual DOM that reconciles existing page HTML and dynamic HTML internally using a non-DOM model. Once the changes are found, a series of small DOM-element replacements are made. Here again, adding <script> tags via the DOM doesn't execute tag contents, so this is safe in any browser.

You still need to look out for attribute-based "event handlers" like onerror, onload, onmouseover, etc, but <script>somethiungBad()</script> is benign if it's not printed by a server or "smartly" added by jQuery. The React framework used in the example might filter those problematic attributes for you, i'm not an expert on React...


How to configure a port as filtered on server With nmap you can see a live system's or server's open, closed, and filtered ports.
But how do you make it show as filtered when it is currently shown as open?

nmap can detect three states for a TCP port:

Open means "SYN" packet got a "SYN/ACK" response ("I hear you, can you hear me?")
Closed means "SYN" packet got a "RST" response ("Firewall REJECT")
Filtered means "SYN" packet got no response at all ("Firewall DROP")

The only way to make an open port seem filtered is to use the firewall to drop packets from the sources you want filtered, and allow packets from the sources you want to allow.  This will make the open port seem filtered to unauthorized sources.  But in order to do that, you need to determine which sources are allowed to connect and configure the firewall rules accordingly.

In other words, you can't have a port be like a "hidden SSID" in wireless, where it's secretly open but you have to know it's there.


Is it responsible to sign an OpenPGP key without verifying person's identity? I frequently use GPG to verify downloads. By doing that I implicitly put trust in a key provided by the author. At least I trust the key enough to run software verified using the given key on my computer. Some examples might be a GNU/Linux distribution maintainer's key published on its homepage (available over HTTPS) or a program author referencing his Keybase.io profile that is intended to be used to obtain a GPG key for singed packages verification.

To mark such a keys as trusted explicitly instead of just importing them into my keyring it looks reasonable to sign them with my key. Persona certification level (0x11) seems to be appropriate in this case. Extending that it might be useful to make my signatures publicly available so a friend of mine downloading a package from the same author could benefit from having the key double-checked as safe to use.

Are there any substantial drawbacks to this approach except privacy concerns?

There are no rules on your personal certification policy. In fact, RFC 4880, OpenPGP states:

  There are a number of possible meanings for a signature, which are
     indicated in a signature type octet in any given signature.  Please
     note that the vagueness of these meanings is not a flaw, but a
     feature of the system.  Because OpenPGP places final authority for
     validity upon the receiver of a signature, it may be that one
     signer's casual act might be more rigorous than some other
     authority's positive act. [...]

I already provided further discussion on the meaning (and vagueness) of certifications in "Is it okay to sign a PGP key without an IRL meeting?".

If you are sure about the software project's key, and also consider it might be relevant to share this attestation, providing a public certification might be a reasonable thing to do. Personally, I also do (but didn't do often, yet), using the very same "sig1/0x11" signature level. If you put deeper thought on what certification levels to use and have a more or less rigid definition, providing a certification policy ("What are you saying when you sign a PGP key?") might be helpful if others actually consider following your certifications in the web of trust.

If you use GnuPG and only want to issue a "private" signature which should not be shared with keyservers and otherwise exported, there is also the local signature (lsign) feature.


Is this a website hacking attempt, and if so, what is it trying to achieve? I've recently seen a few strange requests made on our site, I'm wondering what they might be.

Normally we get sql injection attempts like this:

1111111111%22%20UNION%20SELECT%20CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CH

While I'm no expert, I loosely understand the gist of what's happening there.

But recently I've started noticing ones like this:

redirect:${%23res%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23res.setCharacterEncoding(%22UTF-8%22),%23req%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),%23res.getWriter().print(%22dir:%22),%23res.getWriter().println(%23req.getSession().getServletContext().g`etRealPath(%22/%22)),%23res.getWriter().flush(),%23res.getWriter().close()}

I've never seen anything like that before. I googled it and it seems to related to Apache struts, but I didn't fully understand most of the results (see shot below).

I'm not too sure about the tags for this question - if they can be improved, please do so. Thanks.

It looks like someone is trying exploit an SQL injection vulnerability in struts2 in order to perform remote code execution. See http://struts.apache.org/docs/s2-016.html


Windows process and socket capture I am seeing some suspicious activity on windows 2008 web server. There are some connection attempts being made from the server going out to foreign IP addresses without any legit reason.

The connection attempts are rare, they last only for few seconds. What can I use or How can I find what process in the server has created the socket? It doesn't last for long time so I am thinking of something that will take a snapshot of processes in those few seconds, plus give me the actual process or the actual executable file/dll that opened the socket. Sysinternal TCPview and doing packet capture I can think of, but they are difficult since I don't know when the next connection attempt wil be made. Any better ideas?

I suggest running Network Monitor (from Microsoft themselves) continuously, with a big buffer. NM works with a RAM buffer to save the captured data, and when the buffer is full, old packets are discarded; so you can let it run unattended. Then wait for one of the suspicious connections to happen; at that point, stop the capture and save the trace.

This will give you a fair bit of context (if your buffer is wide enough, a few minutes or even hours of previous traffic). Moreover, NM tries to link data exchanges with the processes (and even when it fails, you can use the trace to understand what was happening on the machine at that precise time, and thus pinpoint the probable culprit).

It also seems that NM can be automated to some extent.


How to retrieve Kerberos Service tickets? I am learning Kerberoasting see below are my steps that I am following.

Step:1. Attacker will find the SPN's
Step:2. After identifying we will request for TGS for that SPN. This is the script for that.

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "<your SPN>"

Step3:. Export it to local disk. mimikatz::list /export

Step:4. Crack it.

Now I didn't understand why the 2nd step is necessary? Because When I skip it directly to 3rd step the Results are Same. Then Why we need that?

Sometimes it might happen that the tickets are not cached in the memory, and so they will not be retrived by mimikatz. So to retrive ticket of the SPN the second step will help in retriving the tickets for the specified SPN if not already cached.


Reducing resolution of timers as mitigation against Meltdown and Spectre I have read that Firefox' current mitigation against Meltdown and Spectre (from 57.x) consists of the following:

  The resolution of performance.now() will be reduced to 20µs.
  The SharedArrayBuffer feature is being disabled by default.

Is it correct to assume that substantially reducing the amount of information obtainable from timing (such as reducing the resolution to 20µs is this case) is a very effective way for addressing the issue in the case of JavaScript runtimes, but that one would introduce lots of (far too many) unwanted side-effects when applying something like this "hammer" to the Linux kernel (hence the additional need for KPTI, etc.)?

The reason it is only applied to browsers is because there is no way to fully eliminate high-resolution timing information from code being natively executed. For example, the RDTSC instruction provides precise, sub-nanosecond resolution timing information to any process. While it is possible to disable this instruction by making it executable only by privileged code (by setting the CR4.TSD bit), much of userland relies on it. However even if you did successfully disable it without breakage, a timer of similar resolution could be jerry-rigged by incrementing a variable in a fast loop. Userspace code will always have nanosecond-precision timing information. Such a timer could be implemented easily:

register volatile unsigned long counter;

void counter_thread(void)
{
    while (1) counter++;
}

The counter_thread() function would be run in its own thread, and in another thread, the value of counter could be sampled at an arbitrary time. As the rate of the counter being incremented would be very high and fairly constant, it would provide a high-resolution timer similar to RDTSC.

As a result, there is no way to hide precise timing information from any process executing directly on the CPU. It is only possible in JavaScript because it is a managed, high-level language which does not have raw access to CPU instructions, and timing must go through dedicated APIs such as performance.now(), which can have its granularity adjusted by modifying the JavaScript engine.


SSL for private network I have a private network, a VPS, an Apache web server and several web pages.

Most documentation about SSL configuration state that I should buy a certificate, and should give the website adress.
However, in my case, it's a private network, none of the pages are seen in the global network.

May I somehow configure SSL for the webpages in my VPS, to connect to the pages via https?

UPDATE

Actually, there are several websites which describe what I want to do. The real problem is that, when I create certificates myself, the webpage everytime says that the certificate is not verified. May I somehow solve this? To buy a certificate is not an option

There are a few things that need to be done in order for you to serve your private networked sites over HTTPS.

You need to setup an OpenSSL based certificate authority.  I don't have a link handy, but you can google it and I am sure you will find what you are looking for.
You need to generate a CSR - certificate signing request which basically provides the details around the site that you are trying to protect with HTTPS, eg the common name, which is the actual URL.
You need to generate a certificate singed by the certificate authority that you created in step# 1.
You will then adjust your web sever or application server to use the SSL certificate and the certificate authority certificate that you created. You should be able to figure the steps for this via a Google query.
Once the certificate is setup on the server, you need to install the certificate authority certificate in your browser. There are a bunch of steps for each of the browsers, Google can help with locating the exact steps.

Once the certificate authority certificate is installed on your client machine's browser, when you visit the URL of your site, using the common name that you provided while setting up the certificate, you should not see a warning, but a green HTTPS padlock in the browser address bar, confirming that the certificate is trustworthy.


Find Virus in an Image File I just received a .jpg file that I'm almost positive contains a virus, so I have two questions about what I am able to do with the image.

My first question originates from the fact that I opened the file once and the program I used to open it gave the error "invalid or corrupt image". So I want to know whether or not its possible a virus contained inside the image could still have been executed if the software did not 'fully' open the image?

My second question is if there is any way to decode/decompile the image data in order to better view its contents. Currently I'm using Notepad++, I just opened the file and am looking at its raw contents, which is one of the reasons why I'm so confident its a virus:

So is there a better way to find out what the virus does and how it works? I need to know whether or not my security has been compromised.

EDIT:

Reasons why I think it contains a virus:

It's way bigger than the image I was expecting
Scan
Looking at contents in Notepad (file)
The way the person who gave me the file acted

Based on the description at Virustotal you've linked to this is in reality not an image, but a real PE32 executable (normal windows executable). So only the file name extension was changed to hide the real purpose of the file.

PE32 will not be automatically executed when they have the .jpg extension like in this case. Also the image viewer which will be invoked with the file by default will not execute the code but instead exit or complain that this is not a valid image.

Thus this file would not work alone. But such files are typically used together with another file which will rename it to name.exe and execute it. This can be done by some batch file, with the help of the Windows Scripting Host ActiveX inside a website or mail or similar. This strategy is used to bypass antivirus and firewalls which might skip analyzing the "jpg" file because of the extension and will not find anything suspicious in the accompanying script (which only renames the file and executes it).

  ...if there is any way to decode/decompile the image data

Again, this is not an image but an executable so the tool of choice could be some disassembler, debugger, sandboxed execution etc. See also the analysis from Virustotal.


How does gcc compiler guard stack for stack overflow? When we compile c program with gcc, we have to inlude "-z execstack" option to enable stack overflow attack.
The question I want to ask is how does gcc implement this .
Without this option, how does gcc guard the stack?
Please explain me in detail if possible.

In a classical stack overflow attack the attacker manages to place its own code (processor instructions) on the stack by overflowing some stack based data structures with attacker controlled content. Now, the attacker needs to have this content on the stack to be taken as instructions by the processor and get it executed. But, the processor will only execute code from memory pages marked as executable. Only, modern OS and compilers will mark the pages of the stack as non-executable in order to prevent such stack overflows. The -z execstack option disables this protection.


Is a monolithic kernel more secure than a microkernel for a small OS? Upon building a kernel for a small CLI system what option is the best one?

I don't know much about what microkernels can do so bear with me if I'm being ignorant:

In one instance, there are monolithic kernels which allow the user control over services before reaching hardware but this could compromise the kernel itself.

On the other hand microkernels do the same thing and software does not reach the kernel but, since it speaks directly to the hardware through the servers, is this making it potentially unstable and insecure?

In theory, a microkernel, by putting the bulk of the driver code into userspace, is more resilient against attacks: an attack against one driver can't easily be used to leverage access to the other drivers, or gain kernel-level privileges.  Additionally, the reduced size of the kernel gives it a much smaller attack surface.

In practice, kernel architecture is only a minor aspect of security.  The designer's attention to security and the quality of the implementation have a far greater impact.


Is an authenticated server seeing the plaintext password a serious problem? Typically a server ends up observing the plaintext password sent by a user at some points (correct me if it is not). Assuming that there is a secure channel established and the data are confidential, while salting and heavy hashing will be performed on the server side. So,

It is a big problem that the server can see the password during authentication?
To what extent could hashing on client side solve this problem, where only h(p) is sent instead of p?

As others have pointed out, client-side hashing doesn't really solve the problem, since the server still sees something that can be reused to authenticate (via a pass-the-hash attack). It's still better than passing the plaintext password, since people reuse passwords (but not salted hashes) between sites/services, and even when they don't they often use similar passwords (/password-choosing systems/etc).

BTW, this isn't just a server security problem. TLS interception (by client-side network security devices) is getting annoyingly common, and any device that does interception also has access to the passwords or hashes.

Fortunately, there's a solution: asymmetric password-authenticated key exchange (PAKE) allows authentication without exposing or storing anything password-equivalent on the server (or to an interception device). Secure Remote Password (SRP) is the best-known and most popular PAKE protocol. There's also a new PAKE protocol proposal, called OPAQUE that looks even better (though I want to see the crypto community beat on it for a while before I'd use it). Matthew Green has a good summary of this here.

Unfortunately PAKEs aren't very widely known or used. IMO, this really should be the standard way of doing network authentication.

Oh, and there is one big limitation: if this is implemented in server-supplied JavaScript, someone with sufficient access to it (or a TLS-intercepting box) can modify the JavaScript that's sent to the client to leak the password. There are ways to improve this somewhat (e.g. with subresource integrity), but even without those PAKEs at least narrow the vulnerability.


Salt addition in hashing? I may be wrong here but reading about salt I was wondering whether if we use the same salt for every password saved in our database won't users having same password would lead to same hash even after adding salt, hence diminishing the sole purpose of adding salt.

If it is true should we only use random salt to the databases?

And what should be an optimal salt length?

Could someone also explain how is the salt decided, whether it is a pre agreed data that is added only through the code or is it saved somewhere from where it is accessed again and again for each and every password.

Yes, if you use the same salt then the same password will result in the same hash.

The general idea behind secure password storage lies in maximising the amount of computational work that an adversary will have to perform should they gain access to the stored credentials.

The purpose of a salt is to mitigate the value of pre-computed (i.e. no additional work as they already exist) hashes. In the case of salt-less storage an adversary can simply compare their list against your stored passwords. If you were to use the same salt then, although a new list of hashes would have to be produced, it would only have to be done once. Per-password salts require a new brute-force attack for each password.

You can store the salt with the hash as its predominant contribution to security lies in its uniqueness (and size) rather than its secrecy.

Here is a good resource, and I would suggest paying attention to the adaptive one-way functions that allow for key stretching:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet


Is hashing without a salt secure for random passwords? I'm designing an API with token authentication.

I don't want to store tokens as plain text in the database, for the same reason user passwords are not stored as plain text: if the database gets compromised, the attacker should not be able to extract any usable token from it.

My current plan is to generate tokens 40 chars in length, composed this way:

the first 20 chars would be the token "ID" (the primary key in the database)
the next 20 chars would be the token "password"

Upon generation of the token, I would send the full token to the client, and store in my database:

the token ID
a SHA1 hash of the token password

This way, my database only holds half of the actual token sent to the client, and can only verify tokens, not retrieve them.

I'm not planning to add a salt: as I understand it, the whole point of the salt is to prevent hash table / rainbow table attacks againt commonly used or short passwords, while in my case passwords are totally random, with enough entropy (67 possible chars, 20 chars in length = 4×1036 combinations). Unless I missed something, adding a salt in this case would be the same as creating a longer random password.

Also, I'm not planning to use an expensive hashing technique such as Bcrypt, as it would be too expensive: unlike user authentication, where the user authenticates once and then gets a session ID, the token is the only method of authentication here and is going to be sent with every single API call; a 50ms hashing method is just not acceptable here. I don't consider having an expensive hashing technique particularly more secure, for the same reason exposed in the previous point: the password is random with enough entropy, so even with a powerful hashing machine, it would still take billions of years to bruteforce.

Is there any flaw in my approach?

The only one I can think of (provided someone gets access to the database!), is if a vulnerability is found in SHA1, so that it becomes feasible to find an input that gives a given hash as output (this somehow happened to MD5, I heard). But I guess this is the same thing for every hashing algorithm out there, Bcrypt included?

It's routine to use a cryptographic hash function for such purposes. The relevant property is called preimage resistance. For a function H it is not feasible to find x such that y = H(x) given an arbitrary y.

(Even SHA-1 has this property, despite not being collision resistant. However, you should still use something else, like SHA-2.)

Preimage resistance is part of what makes a hash function one-way. The best attack against hashed passwords is guess-and-check. If you make totally uninformed guesses against a 512-bit hash then the probability of guessing a valid x is 2-512. The expected number of guesses you need to make before you succeed is unimaginably large.

When it comes to recovering a password from its hash, it doesn't take nearly that many guesses for a typical user's password. Password crackers have a good understanding of what kind of passwords humans choose. They succeed because they prioritize checking plausible candidate passwords.

If someone has an unrealistically strong password, then it is almost certain that the password cracking attempt will fail, just as if the cracker were making uninformed guesses. But since people don't choose nearly strong enough passwords, developers should choose a dedicated password hashing algorithm. The goal of these algorithms is to make the process of testing candidate passwords more expensive. (People should use Argon2id today. It's expensive, relatively efficient on commodity hardware, and harder to parallelize than bcrypt or PBKDF2.)

If every person used passwords that were sufficiently unpredictable, then expensive hash algorithms wouldn't be needed or useful. If each password were unique (and never reused) then salting wouldn't be necessary either. (But salting is necessary for ordinary passwords for multiple reasons.)

If you control the "password" then you can make sure that those values are sufficiently unpredictable. (At that point, you may as well call it a "key".) As long the the hash function is preimage resistant and inputs each are sufficiently unpredictable, then plain old (secure) hashing is safe, even if the table of hashes gets leaked.

Because it doesn't matter if the hashes are leaked, you don't need a separate ID to use as a primary key. The hash of a password itself can be used as the primary key.

(You wouldn't want to do this for user-chosen passwords. A side channel (like timing attack based on database lookup) might leak the hash output, which potentially could allow offline password cracking.)

If the entropy of each token is large enough (256-bits is definitely safe, see "birthday paradox") then you can be assured that each token is unique. Similarly if a hash function's output is large enough, then distinct (real-world) inputs will result in distinct hash outputs. Thus, it is okay to generate a 40 character token, give the token to the user, and store a 64 byte hash in a database (alongside the account ID, expiration time, or anything else relevant).


Is data stored in core data on iOS secure? I'm new to Swift and iOS. Suppose there was no KeyChain API. Would it be safe to put a user's password (plain text) in core data?

Assume it won't be sent over the network, but only stored in the phone. How could an attacker get the password? Could other apps access the info in core data?

If this isn't safe, what steps could be taken to make it safe?

There are multiple parts to this answer. First, everything stored on the file system of an iOS device is encrypted, provided the device uses a passcode. Hence with respect to the data actually on the iOS device, provided you're not trying to hide the data from the user who knows the passcode, you can have some confidence that core data is secure.

However just to be clear, Core Data is not actually a way of storing data. It is a common interface to an object store, which is usually backed by sqlite on the device's file system.

As pointed out by André, this sqlite file may be backed up, leaving it exposed to prying eyes.

Apple's recommendation (that I agree with) is that passwords should only ever be stored in the keychain, which is easy to do, and allows you to control when the entry is accessible (ie. while the device is locked, after first unlock, etc.).

Other apps can never access your app's data in iOS, irrespective of where you write it (unless jailbroken).

Here's a Ray Wenderlich tutorial that walks you through doing this with swift: https://www.raywenderlich.com/92667/securing-ios-data-keychain-touch-id-1password


Is there an advantage to applying pbkdf2 to a key that's used to generate a MAC? We need to generate tamper-resistant URLs to access a service, which are then shared with the end-user. The URLs don't contain any confidential data, but we need to ensure that they have not been tampered with since they were generated. It's up to the end-user to keep these confidential.

It seems like a MAC (like HMACSha256) would be appropriate for authenticating the URLs. I'd also like to include a salt and timestamp to make the MAC key less guessable, and so that the signed URLs can naturally expire.

I was thinking that PBKDF2 might be a good way to generate the MAC key, e.g.:

pepper = "xyzzy"
importantFullUrl = "https://....."

salt = secureRandomBits(256)
url = importantFullUrl + "&ts=987654321&salt=" + base62(salt)

signingKey = PBKDF2(pepper, salt, 10000 /*iterations*/, 256 /*bits*/)
mac = hmacSha256(url, signingKey)
signedUrl = url + "&sig=" + base62(mac)

An alternate approach I've seen skips the PBKDF2 step, and just generates the MAC based on the url and pepper values above, i.e.:

mac = hmacSha256(url, pepper)

Does one approach offer significantly more security benefits over the other? Given the URLs will time out after a period (say, 24-48 hours), does it matter in this case? How do I pick a suitable iteration count for a given timeout?

There's an approach described in this question that involves a user-provided password. Users to our service are authenticated using a different mechanism, and do not explicitly have a password. This is also not for a web service, and all of these signed URLs will be generated server-side, and checked again server-side.

Cryptography should only be used when there is no other option (SSL/TLS is a good example where cryptography is required).  An HMAC always introduces the possibility of the trivial attack (brute force).  Further more, an HMAC can also be a waste of computation effort, when compared to other solutions such as a simple Cryptographic Nonce used to reference the data.

PBKDF2 is used to stretch low entropy input,  such as human generated passwords,  to be used as cryptographic keys.  In order for PBKDF2 to be useful it will consume significant computational effort to produce the resulting hash.  An application exposing this kind of functionality is vulnerable to an Algorithmic Complexity Attack (ACA), and this would be a very serious vulnerability if this was finical software,  because DoS attacks result monetary damages.

PBKDF2 is a useful, especially for passwords, however by exposing this function to an attacker without any form of rate-limiting, creates a potential DoS condition.  SHA256 is just fine for use as an HMAC,  in fact SHA1 would be a better choice for a web application because its faster and the prefixing attacks against SHA1 do not weaken the resulting HMAC. The secret key is what is important,  and you still have to worry about offline brute-force attacks.   But that can be addressed by making the secret key 128 bytes long, which solves that problem for the life our solar system (with some comfort room!).


Is restricting access to file content a way of securing sensible but day to day needed information from 3rd party software? To clarify this directly. I mean what if every (even malicious) 3rd party software running on this OS gets never access to its data and rather 'describes' what to do with?

So for example 'here at index x change this byte to y', 'if at index x is "01" change it to y'. This would obviously be hard for developers to do. That's why I suggest using something like an interface where data types are defined and can be defined by every software. It could range from primites like int,char to literally HTML,JSON and include default operations based on this data type.

Now any software running on this OS needs to handle data with a some kind of interface and will never have directly access to its underlying data.

However this will only apply to files which are publicly accessible like Pictures/Documents, giving the software the possiblity to handle its configuration files ( myapp.conf ) how it wants to, but not the secret Message in secret_text.txt (making sure these files cannot accessed by anyone, but the creator/application).

The GUI is really tricky because it has to display the actual data to the user. Therefore it needs to a part of the OS, otherwise the effort is worthless.

Now I got a few questions I can't answer myself:

will exploits effect this design in more dramatic way than on Linux/Windows?
how much of a benefit do I get compared to different approaches?
in which way are applications limited by this design?
where should this approach be implemented? (Kernel space/User space)
due to the reason that the GUI needs to be a part of the OS what are downsides or benefits from this?

So, with this questions in mind, will this be a secure way of handling (sensitive) data?

PS: It is my first question here, if anything is unclear please let me know.

If I understand this question correctly, you are proposing a system where applications never gets to read a file, but only send commands to an interface that reads and modifies data. That way, the application will know nothing about the data it operats upon. That is not going to work as a way to protect your data. Let me explain why.

So let's say I have some photos I want to crop, but I don't want my photo editing application to see them. The photo editing application would then just send the crop command to the JPG interface, and the interface then does the cropping.

And if I want to see the image on the screen while I crop it, I guess the interface will have to take care of that as well. And if the photo app window should resize to fit the image, the interface would have to do that as well because the app wouldn't know the size of the image. But know the photo app doesn't know the size of it's own window... so how can it control what buttons are shown in the toolbar? I guess the interface will have to take care of that too.

Do you see what is happening here? The interface is taking over all the complexity that the app handles. There simply is no clean interface between reading and writing, so the interface will just swallow more and more of the app until the app is just an empty shell around the interface.

And if the interface is as complex as the app used to be, one has to ask the question: Where does the interfaces come from? People will just be downloading trojan filled interfaces instead of trojan filled apps.


I am unable to use an RSA key generated with the -aes-256-gcm option in openssl, help When I run:
openssl genrsa -aes-256-gcm -out rootca.key 4096

Then I get the following output:
$ openssl genrsa -aes-256-gcm -out rootca.key 4096
Generating RSA private key, 8192 bit long modulus (2 primes)
..........................................................+++
..........................................................................+++
e is 65537 (0x010001)
Enter pass phrase for rootca.key:
Verifying - Enter pass phrase for rootca.key:

And when I run:
openssl req -sha512 -new -x509 -days 1000 -key rootca.key -out rootca.crt

I get the following error:
$ openssl req -sha512 -new -x509 -days 1000 -key rootca.key -out rootca.crt
Enter pass phrase for rootca.key:
unable to load Private Key
140287193601344:error:0906A065:PEM routines:PEM_do_header:bad decrypt:../crypto/pem/pem_lib.c:461:

For the above, I used OpenSSL 1.1.1f (provided by apt.
I even tried using the latest 3.0.0-alpha version of OpenSSL. But I get a different error when generating the private key first of all:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
4067E7A7827F0000:error:0300007A:digital envelope routines:evp_cipher_param_to_asn1_ex:cipher parameter error:crypto/evp/evp_lib.c:160:
4067E7A7827F0000:error:06800072:asn1 encoding routines:PKCS5_pbe2_set_iv:error setting cipher params:crypto/asn1/p5_pbev2.c:81:
4067E7A7827F0000:error:1188000D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:crypto/pkcs12/p12_p8e.c:32:

How can I make this work?? Is AES-256-GCM not supported by OpenSSL? If so, is there an alternative to OpenSSL that can generate this type of key?
Btw, AES-256-CBC works perfectly. But, no luck with GCM.

WRT, "I am unable to generate and use an aes-256-gcm key in openssl":  Understand that openssl genrsa is used to generate an asymmetric RSA key pair. openssl genrsa is not used to generate a symmetric AES key.
The -aesxxx option that you are trying to use with the openssl genrsa command does not change the type of key that openssl genrsa generates.  This option is simply used to encrypt the RSA private key that openssl genrsa generates (using a key derived from a password that it prompts you for).
As for why you are getting the error that you show in your question, it may be related to the fact that -aes-256-gcm does not seem to be a supported option for 'openssl genrsa` according to the documentation for openssl 1.1.1 at https://www.openssl.org/docs/man1.1.1/man1/openssl-genrsa.html.  However, -aes256 is supported.
FWIW, An AES-256 key (regardless of which mode of AES is used, e.g. AES-256-CBC, AES-256-GCM, etc) is just 256 bits.  It's easy to generate a random 256 bit AES key, without even using openssl.  You can do:
head /dev/urandom | sha256sum


How does forward secrecy beat public-key encryption if the key is regularly updated? Why is forward secrecy better (say for WhatsApp) than public-key encryption with a routinely revised key?

The advertised issue is backwards safety: If at a point one key is compromised, someone storing the history of past communications would still be unable to suddenly decrypt all that history.

But consider the following simpler method using ordinary public-key encryption. Whenever Bob's client sends a message, it sends along with that message a new public key, one generated algorithmically. The public key is stored on the (WhatsApp's) server. Those sending messages to Bob would retrieve that public key, and their client would encrypt the message they are sending to Bob using that key. The key remains valid until Bob again sends a message to anyone.

What is the weakness of this elementary approach compared to forward secrecy? Once one message under forward secrecy is compromised, subsequent messages would become readable. The method just described would be stronger in that respect.

Well forward secrecy is usually achieved exactly by what you propose, namely ephemeral public (usually Diffie-Hellman) keys. This basically works as follows:

Generate some DH parameters.
Sign the public parameters via your longterm public key.
Send parameters and your signature over the parameters to whatever computer you want to talk to.
Use the ephemeral parameters to generate a shared secret from which to derive symmetric keys.

If you look at the key exchange mechanism for most HTTPS connections you'll see part of the ciphersuite is usually ECDHE_RSA, meaning ephemeral Diffie-Hellman (over an elliptic curve group) with the parameters signed via RSA (the RSA key being the servers long-term private key for which the corresponding public key is found in the servers certificate).

It is important that you sign your ephemeral keys with your long-term private key, otherwise an attacker would be able to upload a key of their choice to say the WhatsApp servers and read all messages intended for you as there would be no way to verify the ephemeral keys legitimacy.

  Once one message under forward secrecy is compromised, subsequent messages would become readable. The method just described would be stronger in that respect.

This is not correct, only messages related to the session whose ephemeral parameters were compromised would become readable. The next session would have different ephemeral parameters and would still be secure.


How can a very small company handle PCI-DSS requirement 6.4.2? PCI-DSS 3 requirement 6.4.2 calls for

  Separation of duties between development/test and production environments.

Based on the guidance text and  this, answer to another question, it appears that the purpose of this requirement is to ensure that no one person holds all the access.

While this is easy enough in a large company, does this automatically mean that a 1 person company (or a company small enough to be unable to afford hiring separate DBAs and syadmins for each environment) cannot possibly be PCI-DSS compliant?

In general, a shop which is that small will not handle credit card processing directly. They will outsource that functionality to a 3rd party which is PCI compliant. The responsibility will be to ensure the 3rd party is compliant.

If this is not an option, then it will be necessary to put other controls in place which will satisfies your QSA. What these controls will need to be will depend o the volume of credit card transactions you process. This could be things like higher logging and more frequent external auditing, role rotation, establishing processes where multiple individuals need to participate in applying changes in production etc.


browser can visit the url but other application can't I did simple 'intitle:"index of" xss' search and got this page with URL 'https://repo1.maven.org/maven2/com/codesnippets4all/xss-filter/'.I can see the IP on the wireshark and the conversation of machine and server with tcp stream but not able to ping it or namp scan it directly or with SYN scan

result when ping to the url :- Name or service not known
result nmap  when simple full connect scan:-Unable to split netmask from target expression: "https://repo1.maven.org/maven2/com/codesnippets4all/xss-filter/"
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.16 seconds
result nmap when syn connect:-Unable to split netmask from target expression: "https://repo1.maven.org/maven2/com/codesnippets4all/xss-filter/"
WARNING: No targets were specified, so 0 hosts scanned.
wireshark log

My question is why can a browser can connect to it but not a ping application or nmap. what is the reason for such a behavior?
Sorry if this is a dumb or a bit redundant question.
Thanks in advance.

My question is why can a browser can connect to it

A browser will connect over TCP, by default to a port that is normally open on a web server. Web servers normally use port 80 (plain-text HTTP) or port 443 (HTTPS), and unless the administrator deliberately chooses to use a non-standard port (which then must be specified in the browser address field), any server that is used to serve web content will necessarily have to allow a client to access either or both of these.

  but not a ping application

Ping uses what is technically known as ICMP Echo Requests and their corresponding ICMP Echo Responses. It is not at all uncommon to block these either at the host level or a perimeter firewall. ICMP is a protocol that runs on top of IP, in the same way as TCP or UDP, but is conceptually considered a sibling of IP rather than a sibling of TCP or UDP. See RFC 1122 section 1.1.3 Internet Protocol Suite, page 10. ICMP is unrelated to HTTP, and being able to connect to a standard HTTP port has no bearing on whether a host will accept a particular ICMP message from the same origin IP address. (Note that ICMP is used for many other things besides ping; it's called the Internet Control Message Protocol for good reason. Wikipedia has a handy summary of all ICMP control messages.)

  or nmap

nmap is what is known as a port scanner (among several other things). Port scanning is often a high-intensity activity that can easily be detected and subsequently blocked, and I wouldn't be the least bit surprised if many large web sites have just such things in place.

TL;DR: You are doing completely different things. Getting different results is normal and actually should be expected.


aircrack-ng fed with crunch taking ages I'm trying aircrack-ng attack like below:

crunch 1 2 -f /usr/local/Cellar/crunch/3.6/share/charset.lst mixalpha-numeric|aircrack-ng -b 90:F6:52:80:B9:E2 -w - ~/DumpLog*
⋮
Crunch will now generate the following number of lines: 221918520426688
⋮

and it can't finish. I see that it should go through Petabytes in relatively small amount of time (here's example of 10 letter pwd cracked in 30mins: Cracking WPA key with crunch | aircrack)

I've tried simply

crunch 1 2 -f /usr/local/Cellar/crunch/3.6/share/charset.lst mixalpha-numeric|aircrack-ng -b 90:F6:52:80:B9:E2 -w - ~/DumpLog*
Crunch will now generate the following amount of data: 11656 bytes
0 MB
0 GB
0 TB
0 PB
Crunch will now generate the following number of lines: 3906
Opening /Users/msciwoj/DumpLog 16-04-19 00:02
Opening /Users/msciwoj/DumpLog 16-04-19 22:48.1
Opening /Users/msciwoj/DumpLog 16-04-20 16:06
Reading packets, please wait...
                             Aircrack-ng 1.1
Passphrase not in dictionary

and it's taking ~30seconds (for only 4k combinations!)

What am I doing wrong? Is there better/faster method (than crunch) to
generate all possible permutations?
Is there anything wrong with the capture files I have:

.

ls -l ~/DumpLog*
-rw-r--r-- 1 msciwoj 388572231 Apr 19 16:29 /Users/msciwoj/DumpLog 16-04-19 00:02
-rw-r--r-- 1 msciwoj 856313817 Apr 20 08:41 /Users/msciwoj/DumpLog 16-04-19 22:48.1
-rw-r--r-- 1 msciwoj 426269497 Apr 20 22:10 /Users/msciwoj/DumpLog 16-04-20 16:06

could the fact I'm on Mac OS X have to do anything with it?

As Daisetsu said, you're not doing anything wrong: CPU is just very slow at hashing WPA passwords. While I don't have experience on it, OSX shouldn't be a problem either.
The WPA/2 spec demands 4096 rounds of HMAC-SHA1 hashes to derive the final key. This equates to 16,384,000 general HMAC-SHA1 hashes/second at ~4k keys/second. Individually, they're rather fast. However WPA was designed in part to make brute force attacks harder (as well as more secure in general), and thus implemented many rounds of hashes instead of using just one.
Relying on CPU for cracking WPA isn't going to get you very far, as you've noticed. A much faster method would be GPU cracking. Even without a powerful GPU, you'll most likely get better results.
In my eyes, there are two major contenders in the GPU cracking game: hashcat and Pyrit;
hashcat
Site: https://hashcat.net/hashcat/
Tutorial: https://www.blackmoreops.com/2014/03/27/cracking-wpa-wpa2-with-hashcat-kali-linux/
hashcat is great if you don't have a lot of hard drive space. You can feed it input with crunch (like you're doing now), and it supports an incredible amount of algorithms; not just WPA. If you stop hashcat, you can pick it up later by specifying the start string in crunch, as hashcat gives you regular updates on its speed and current password as well as other things.
Pyrit
Site: https://github.com/JPaulMora/Pyrit
Tutorial: https://www.blackmoreops.com/2014/03/10/cracking-wifi-wpawpa2-passwords-using-pyrit-cowpatty/
Pyrit is great for precomputational attacks. Pyrit allows you to specify an SSID (since the SSID is used in the HMAC algorithm) and compute a table of keys based off of an input (be it a file or crunch) and keep them. If you knew the SSID you were after (say, Netgear; a default name) you could just compare the keys without having to recompute them over and over again. This is great because the comparison process is incredibly easy and will still use the gpu. With my SLI GTX650TI boost setup, I got about 55k hashes/second, and one-hundred million comparisons/second (if my memory is correct; this was a while ago).
Pyrit is more useful in the long run, as you have only to compute the keys once, then compare them with the captured handshake in your pcap files. With hashcat, you can get to cracking and comparing at the same time without the need to precompute everything and then compare it.
The difference is time: if you have an 8 character password, and you're going to try all possible combinations from aaaaaaaa to zzzzzzzz and your password was mmmmmmmm, Pyrit would have to compute all possible keys from aaaaaaaa to zzzzzzzz and then compare it, whereas hashcat would would get to mmmmmmmm, hash it, compare it, and tell you its found the answer without having to go through all the other possible candidates.
Now, if you then changed the password and wanted to compare another handshake, then Pyrit would be your boy, as you've already computed all the keys for aaaaaaaa to zzzzzzzz for that SSID, whereas hashcat would have to recompute them. Basically, if you will re-use an SSID many times, go for Pyrit. If its a one off, use hashcat.
As for raw speed numbers, this site has a very nice table comparing the speeds of many different graphics cards. In my experience, hashcat and Pyrit have about the same hashing speeds, so if that number is your main concern, using either GPU hashing program will yield approximately the same results. Your main concern between programs will be the re-use of that SSID.
I hope this makes sense. If not, let me know and I'll try to explain it better!


Do large companies use multiple public-private key pairs? If I were to create a website I would then naturally generate a public-private key pair. The public key is published and the private key is kept private on the server. If the website has not a lot of traffic I would probably use this key pair for all communication.

I could imagine that a large company like Google would create a key pair for all communication from/to the USA and use a different key pair (simultaneously) for all communication from/to France, etc.

Do large companies use multiple public-private key pairs and if so, for what reason?

Websites use x509 certificates which uses public key cryptography (public private keypairs).

Even small companies have many different certificates, and many different public private key pairs. The idea is if one system is compromised and a private key is exposed, you wouldn't want to risk traffic on another system.

Think of it this way. Would a multinational company use the same lock with the same key on all their doors at all their facilities?  No way!  They have a different lock on every door.

There's so much to this topic, certificates, CAs, trust chains, etc. You may want to read up on how certificates and TLS works.

Companies will also use public key cryptography for logging onto computers, their email, and a myriad of other things.


Can not setting password for root when installing linux be exploited? Recently I've been thinking about how I installed my linux system (I went for debian). When I installed it, I chose not to enter password for root and only entered password for my user account. My question is whether it can be somehow exploited and is it possible to login as root when I didn't provide any password? I tried

su
Password:

but mine password obviously didn't work. Thank you!

If you are worried about something or someone abusing this lapse and ending up logging in as root, don't worry: if root has no password set, no password will match and plain common login with that account (tty login, SSH login, X login, et al) will not be allowed.

But the account is still accessible: you can sudo su and become root. After that you can add a public key to /root/.ssh/authorized_keys and SSH-in as root.

But none of those methods will work when you don't have sudo powers, and you are probably the only one with that power on your system.


Which is the main purpose of having two domains pointing to the same IP, one of them without SSL/TLS? During the information gathering phase I found that there is another domain pointing to the same IP that I'm auditing. The first one, "www.domain.com", is using TLS whereas the second one, "www-org.domain.com", isn't. The two domains offer the same funcionality. Is there any purpose of having the second domain?

One of the reasons could be that some old system needs to operate with the one that don't have TLS support, but nowadays is a it strange that you don't have TLS support on the client


Most widely used non Cryptographic random number generators I want to research pseudo random number generators, and I see that a lot of the random number generators are not as secure as people assume.

What I would like to know is what are the most widely used random generators currently ? Be it PRNG or CSPRNG. This is under my assumption that TRNG has not yet become as common as the former generators. I would like to understand how frequently PRNGs are used in security applications, when CSPRNGs should have been used instead.

Mersenne Twister is a non-cryptographic RNG that's commonly used in many applications. According to Wikipedia:

  The Mersenne Twister is the default PRNG for the following software systems:

  Microsoft Visual C++,[3] Microsoft Excel,[4] GAUSS,[5] GLib,[6] GNU Multiple Precision Arithmetic Library,[7] GNU Octave,[8] GNU Scientific Library,[9] gretl,[10] IDL,[11] Julia,[12] CMU Common Lisp,[13] Embeddable Common Lisp,[14] Steel Bank Common Lisp,[15] Maple,[16] MATLAB,[17] Free Pascal,[18] PHP,[19] Python,[20][21] R,[22] Ruby,[23] SageMath,[24] Scilab,[25] Stata.[26] It is also available in Apache Commons,[27] in standard C++ (since C++11),[28][29] and in Mathematica.[30] Add-on implementations are provided in many program libraries, including the Boost C++ Libraries,[31] the CUDA Library,[32] and the NAG Numerical Library.[33]

Mersenne Twister is a very good PRNG, with good statistical properties, very long period, and is fast. Despite being a very good PRNG, and is widely used for many games, statistical simulations, and other purposes, it's not suitable for cryptography.

Another common RNG is linear congruential generator (LCG), which for a long time is the default RNG in popular C libraries (and many other languages that uses C library, such as PHP). LCG is a simple but very poor RNG, even for non-cryptographic RNG standards. Its period size is embarrassingly small, already-produced numbers cannot repeat for the entire period, and it has statistical properties that makes it unsuitable for many purposes.


Rationale for security lockout after changing a password I was recently locked out of an account (for 30 minutes), not for failing a certain number of attempts at a password, but instead for changing the password after answering security questions.

What do you think the purpose of this security mechanism is?

I was under the impression that the only purpose of a lockout was to prevent brute force password attacks. Since the purpose of security questions is to prove identity without a password, I can't fathom why a lockout would be used in this situation.

I am with @Cowthulhu about the cooldown time.

Lastpass uses something similar for their recovery access: you can designate someone as trusted, that person can request an access to your password vault, but will have to wait a predefined time (predefined by you, from nothing to a few days) to give you time to revoke the access. In the meantime you recieve an email stating that a request was done.

Have you received a message from the site owner right after the change with some similar information ("your password was changed but the user is locked for 30 minutes, if it was not you contact us during that timeframe so that we revert the change")? Since you asked the question - I guess not, but maybe this is buried somewhere in the informational email.


PFS incentive during IKE Phase 2 I'm trying to see the actual point in implementing Perfect Forward Secrecy during Internet Key Exchange Phase 2, if it had already been used during Phase 1.
Quoting the IKEv2 RFC:

RFC 5596
3.3.2.  Transform Substructure
[...] Although ESP and AH do not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, providing perfect forward secrecy for the generated Child SA keys.

Is there a real security incentive to implement this forward secrecy feature?
What is the risk it tries to cover?
My understanding is that, without PFS here, the Child SA (Security Association) keys are derived directly from the keys negotiated during Phase 1.
If an attacker gets his hands on the dynamically generated keys negotiated during Phase 1 (in memory or after breaking the involved cryptography), I cannot see why he could not get the new ones generated during Phase 2.

The idea of PFS is that not all keys are equal, when considering risks of ulterior theft. A private key stored in a file may be stolen afterwards, e.g. if the disk fails and is carelessly discarded. On the other hand, a key which resides in RAM only disappears when the machine is shut down or rebooted, and thus is unlikely to be recovered by an hostile entity. In the PFS security model, we care mostly about keys which are not generated dynamically, but stored on physical mediums for arbitrary amounts of time.

When using Diffie-Hellman, it is not the use of DH which grants PFS; what grants PFS is not storing the DH private key. DH or an elliptic-curve variant is often used in protocols which seek PFS, because PFS implies generating a new key pair on-the-fly, and generating a DH or ECDH key pair can be done very efficiently (as opposed to, say, RSA).


metasploit+openvas error switched to openvas a couple days, is open and does the job.. so far so good, but I hit a wall.. with metasploit I load the module, I log in, fine.. but when I run some tasks I get some errors.. I think the plugin needs to be update..

> openvas_report_import 2 NBE
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
/usr/share/metasploit/lib/openvas/openvas-omp.rb:102:in `sendrecv': Object#timeout is deprecated, use Timeout.timeout instead.
[*] Importing report to database.

Seems like nobody is maintaining the code for openvas plugin? anyone has experienced this? if I sed that file for the timeout objet and sed it to Timeout.timeout will it work?

thanks in advance.

ok so I went ahead and did try and that seem to have worked
now no error.

msf > openvas_report_import 2 14
[*] Importing report to database.
msf >

so

vim /usr/share/metasploit/lib/openvas/openvas-omp.rb

and change the line where  timeout to Timeout.timeout

openvas]$ ruby -c openvas-omp.rb
Syntax OK


BlackBerry client authenticating to Java Web Service I already asked this question at StackOverflow here: https://stackoverflow.com/questions/4970681/blackberry-app-security and was directed to this site, can anyone pitch in as to how I can solve this issue?

Users log in to my BlackBerry app with a username and password provided at registration. My app connects to a Java Web Service that does all the logic.

How do I go about storing the password and username in a safe manner on my server? Everybody says salting and hashing, but I have no idea how to do this since I've never worked with it. How can I do this in Java?
How do I manage sending the password securely from the app to the server?

There is a good explanation of this on the OWASP website, see the page Hashing Java.
It explains some of the details about the use of hashes and why to add a salt, it also contain code examples. This may be a good point for you to start from.

As for securing sending the passwords from the app using HTTPS instead of HTTP if your not already would be a good start.


Manage Browser Cookie Editing for web application in .Net Mvc I am developing a sensitive web application with .net MVC and I am saving my user credentials after login with cookies.

The problem is, one user is able to login with their username and password. Then he/she is able to edit the cookies and reset cookies to another user id. It's causing a security issue. How can we prevent that?

Use a cryptographically safe cookie value such that modification of the value would invalidate the session. In other words

cookie = encrypt(username, expiration, secret)

Where only your application knows the secret. With that said, don't do this yourself. There are a ton of ways this can be done securely in MVC.


Do I lose the anonymity of a VPN if they open a port for me? I currently use a VPN supplier that does not allow for opening ports. They argue that I lose the whole point of a VPN and the anonymity by doing this. I can't see how and they don't seem to be able to explain how this would work for me.

Shouldn't I still be protected behind the NAT of the VPN?

Opening a unique port just for you? Yes, you lose anonymity, even with NAT, because now that traffic on that unique port unique identifies your traffic.

One of the benefits of a VPN is that your traffic gets co-mingled with so much other traffic that it is difficult to uniquely identify users. Your proposal eliminates this benefit.