Model–View–ViewModel (MVVM) is a common pattern used in WPF, Xamarin, and other types of .NET applications. There are different ways to apply the MVVM pattern, but they all share a few underlying concepts. I’d like to discuss these concepts, and how to successfully configure protection with Dotfuscator for MVVM-based apps.
Credentials are a problem for your app. Why? Because they’re a critical access gateway: If attackers get their hands on working usernames and passwords they can cause havoc — everything from stealing user accounts to compromising high-level application functions.
It’s big business; Sensor Tech Forum notes that 85 malicious apps on Google Play were stealing login credentials, while Verizon’s 2018 Data Breach Investigation Report found that 81 percent of hacking incidents used weak or stolen passwords.
And while part of the problem rests with users choosing username and password combinations that are easy to remember and easy for attackers to guess, applications have their own issue: Hard coding. From smart city software to stock trading applications, the use of hard-coded credentials saves time upfront but significantly impacts security.
Don’t become an easy mark for hackers: Here are six ways to boost credential control and reduce total risk.
In 2017 and again in 2018, PreEmptive Solutions surveyed over 15,000 professional developers asking about their organization’s current and projected use of a broad cross-section of development languages and frameworks.
Evaluating each annual survey result on its own and again together as a whole offers insights into current practices, assumptions about future trends as well as the actual trends that played out during the time between the two survey collection points.
The white paper, The Future of Language and Framework Survey shows a professional development community striving to reduce the number of languages and frameworks they rely upon while simultaneously increasing their commitment and investments in the technologies they retain. As this maturation occurs, overall clarity and confidence in their architecture and mission improves.
Prevention, detection, and response
Today, Microsoft announced Azure DevOps – Loosely, it is TFS and VSTS, with its services broken out into distinct components that can be used together or separately. The Azure DevOps services are Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans and Azure Artifacts. When Azure DevOps was VSTS and TFS, we supported integration with PreEmptive’s Dotfuscator. Today, none of that changes. As Azure DevOps evolves, we will continue to improve our integration, so that you can easily add multi-layered protection to your valuable apps.
In Mindset shift to a DevSecOps culture, Buck Hodges, Director of Engineering for Visual Studio Team Services, stressed the importance of both preventing breaches and “assuming breaches. ”In essence, prevention only gets you part of the way there. “Assuming a breach” allows for effective incident detection, response and recovery process planning.
The .NET Conference is right around the corner. Make sure to mark your calendar because this virtual three-day developer event is not one you will want to miss. Included will be a wide variety of live sessions for beginners to advanced developers to attend.
Learn to build and the latest techniques for:
The release of Dotfuscator v4.37 yesterday marks the first big step toward a major goal: to modernize our Visual Studio integration. This release is numbered as a "minor" release - because, as always, we work hard to not make breaking changes - but its significance is actually very major.
Our current Visual Studio integration has always been one of the primary user interfaces for Dotfuscator; nearly half of our users use it, or have used it. Of those users, most are quite happy with it. (So we know that changing it is no small undertaking!)
However, there are some users who can't use it, or for whom it doesn't work very well. Notably, users with especially large projects, or complex build configurations, or more-modern projects that have heavy packaging components (including Xamarin and UWP), have all only had the option of our "standalone GUI" and a custom-made build integration.
Despite the rising costs and impact of application compromise — recent data found that 58 digital records are stolen every second and breaches cost companies an average of $3.6 million — many best practices and procedures for securely designing, developing, testing and protecting applications are largely ad-hoc. As noted by Tech Republic, in fact, exactly ZERO percent of organizations say their security needs are fully met by their current infosec strategy, down from just 11 percent last year.
Some respondents pointed to a lack of skilled resources while others cited budget constraints, but regardless of origin the outcome is clear: Hastily-designed app protection procedures that don’t meet current needs and can’t keep up with evolving demands.
Need a helping hand with your application protection process? We’ve compiled some of the best practices of leading-edge companies into a top-10 list. Let’s get started.
DashO v9.0 is out, and it has a new major version number for a very good reason: we've made some major improvements!
Java 9 and 10 support, including module support
In DashO v8.4, we introduced "provisional" Java 9 support, and we published an article describing our Java 9 roadmap. Java 9 support was provisional because there were cases where DashO would process a Java 9 app in a way that DashO thought was correct but would actually result in a broken app. As part of our commitment to the "principle of least surprise", we didn't want users to discover those issues by accident, so we made Java 9 support require an opt-in.
As of DashO 9, Java 9 (and 10) support is no longer provisional; it is a fully-supported feature, without an opt-in - and without surprises. There are a few edge cases, still, but those will generate build warnings or errors, as appropriate.