<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Web Application Topics on Rietta Cybersecurity</title>
    <link>https://rietta.com/tags/web-application-topics/</link>
    <description>Recent content in Web Application Topics on Rietta Cybersecurity</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>1999-2026 Rietta Inc. All Rights Reserved.</copyright>
    <atom:link href="https://rietta.com/tags/web-application-topics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Bad Password Practices are Responsible For Most Data Breaches. You Can do Better.</title>
      <link>https://rietta.com/blog/bad-password-practices-are-responsible-for-most-data-breaches-you-can-do-better/</link>
      <pubDate>Tue, 10 May 2016 11:07:58 -0400</pubDate>
      <guid>https://rietta.com/blog/bad-password-practices-are-responsible-for-most-data-breaches-you-can-do-better/</guid>
      <description>&lt;p&gt;The &lt;a href=&#34;http://www.verizonenterprise.com/verizon-insights-lab/dbir/&#34;&gt;2016 Verizon DBIR report&lt;/a&gt; is out and is available for download. Among the findings is the prevalence of data breaches that are attributable to stolen authorization credentials.&lt;/p&gt;&#xA;&lt;p&gt;According to the report &amp;ldquo;63% of confirmed data breaches involved weak, default or stolen passwords&amp;rdquo; (page 20). This is an increase from 2015, when the stat was that 51% of web application breaches were attributable to stolen credentials. If anything is clear, it&amp;rsquo;s that the lowly credential theft is a clear and present danger in information security. It is responsible for more incidents than all the other exotic, technically interesting attacks combined.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What is the difference between bcrypt and SHA256?</title>
      <link>https://rietta.com/blog/bcrypt-not-sha-for-passwords/</link>
      <pubDate>Fri, 05 Feb 2016 10:23:27 -0500</pubDate>
      <guid>https://rietta.com/blog/bcrypt-not-sha-for-passwords/</guid>
      <description>&lt;p&gt;TL;DR; SHA1, SHA256, and SHA512 are all &lt;em&gt;fast hashes&lt;/em&gt; and are bad for passwords. SCRYPT and BCRYPT are both a &lt;em&gt;slow hash&lt;/em&gt; and are good for passwords. Always use slow hashes, never fast hashes.&lt;/p&gt;&#xA;&lt;p&gt;SANS&amp;rsquo; &lt;a href=&#34;https://software-security.sans.org/resources/swat&#34;&gt;Securing Web Application Technologies&#xA;[SWAT] Checklist&lt;/a&gt; is offering a bit of bad security advice for the everyday web application developer, under the heading &amp;ldquo;Store User Passwords Using A Strong, Iterative, Salted Hash&amp;rdquo;:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;User passwords must be stored using secure hashing techniques with a strong algorithm like SHA-256. Simply hashing the password a single time does not sufficiently protect the password. Use iterative hashing with a random salt to make the hash strong.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>What is an Abuser Story (Software)</title>
      <link>https://rietta.com/blog/what-is-an-abuser-story-software/</link>
      <pubDate>Sun, 11 Oct 2015 22:35:36 -0400</pubDate>
      <guid>https://rietta.com/blog/what-is-an-abuser-story-software/</guid>
      <description>&lt;p&gt;I publicly speaking about how development teams and those who employ them should go about using user stories with security constraints and abuser stories as a security documentation tool. At this time there is not an entry on Wikipedia about it, so I am going to take a stab at writing it up for you here.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-is-an-abuser-story-in-software-development&#34;&gt;What is an Abuser Story in Software Development?&lt;/h2&gt;&#xA;&lt;p&gt;In software development and product management, an abuser story is a user story from the point of view of a &lt;a href=&#34;https://en.wikipedia.org/wiki/Adversary_(cryptography)&#34;&gt;malicious adversary&lt;/a&gt;. Abuser stories are used with agile software development methodologies as the basis for defining the activities that should be actively blocked or mitigated by the software and proven by automated regression testing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Adding a Rake Task for SQL Views to a Rails Project</title>
      <link>https://rietta.com/blog/adding-rake-db-views-for-sql-views-to-a-rails-project/</link>
      <pubDate>Mon, 30 Mar 2015 12:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/adding-rake-db-views-for-sql-views-to-a-rails-project/</guid>
      <description>&lt;p&gt;I have previously written about &lt;a href=&#34;https://rietta.com/blog/rails-and-sql-views-for-a-report/&#34;&gt;Using Rails and SQL Views for a Report&lt;/a&gt;. A practical consideration when employing SQL views, which create wonderfully fast read-only tables that can be used by ActiveRecord models seamlessly, in a Ruby on Rails project is where to maintain them in a project.&lt;/p&gt;&#xA;&lt;p&gt;One approach is to use migrations, since that&amp;rsquo;s where database stuff normally goes. But a big downside is that this approach is not &lt;acronym title=&#34;Do Not Repeat Yourself - a common Ruby community refrain&#34;&gt;DRY&lt;/acronym&gt; because changing the SQL view requires a new migration that drops the old view and replaces it with the updated version. &lt;em&gt;Simply changing a field in the SQL view requires copying and pasting the entire definition over again&lt;/em&gt;. That&amp;rsquo;s just annoying!&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;The second, and in my opinion better approach, is to treat SQL views more like models.&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Issue #6: February, 2014, Web Application Topics Newsletter</title>
      <link>https://rietta.com/blog/newsletter-issue-6/</link>
      <pubDate>Tue, 18 Feb 2014 07:31:00 -0500</pubDate>
      <guid>https://rietta.com/blog/newsletter-issue-6/</guid>
      <description>&lt;h2 id=&#34;in-this-issue&#34;&gt;In this issue&lt;/h2&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://rietta.com/blog/newsletter-issue-6/#gitbash&#34;&gt;Get and compare the current Git branch in BASH&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://rietta.com/blog/newsletter-issue-6/#book&#34;&gt;New book of the month&lt;/a&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;em&gt;Don&amp;rsquo;t Make Me Think&lt;/em&gt;, 3rd Edition&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://rietta.com/blog/newsletter-issue-6/#news&#34;&gt;In the news&lt;/a&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;PaperClip (Ruby on Rails) Insecure Defaults&lt;/li&gt;&#xA;&lt;li&gt;Yahoo user accounts compromised through third party database breach&lt;/li&gt;&#xA;&lt;li&gt;Buffer database compromised through compromise of MongoHQ support credentials&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Why &amp; How We Remote Pair Program (2013)</title>
      <link>https://rietta.com/blog/why-and-how-we-remote-pair-program-2013/</link>
      <pubDate>Tue, 07 Jan 2014 16:38:00 +0000</pubDate>
      <guid>https://rietta.com/blog/why-and-how-we-remote-pair-program-2013/</guid>
      <description>Brandon Dees and I gave a this talk about how and why we do remote pair programming when he lives in Nashville, TN, and I live in Johns Creek, GA (a 416 mile round trip) on Wednesday, October 9, 2013 at the Atlanta Ruby Users&amp;rsquo; Group (ATLRUG).&#xA;The Video The excellent Q&amp;amp;A starts at 31 minutes into the talk!&#xA;The Slides The slides are available directly Why &amp;amp; How We Remote Pair Program at Speakerdeck and here is the link to video directly on YouTube.</description>
    </item>
    <item>
      <title>Joppar&#39;s &#39;Tips on Securing Your Mobile App&#39; Infographic Quoted Me!</title>
      <link>https://rietta.com/blog/tips-on-securing-your-mobile-app/</link>
      <pubDate>Mon, 06 Jan 2014 11:26:00 +0000</pubDate>
      <guid>https://rietta.com/blog/tips-on-securing-your-mobile-app/</guid>
      <description>Good morning! I write this on the very cold Monday morning that is January 6, 2014. Today, our friends over at Joppar, a mobile apps startup in Silicon Valley, have released a very good cheat sheet for app developers who want to care about the security of their application. In other words, anyone who does not want their own &amp;lsquo;Snapchat Breach Exposes Weak Security&amp;rsquo; article from the New York Times.</description>
    </item>
    <item>
      <title>OpenSSL: Encrypt Data with an RSA Key with PHP</title>
      <link>https://rietta.com/blog/openssl-encrypt-data-with-rsa-key-with/</link>
      <pubDate>Thu, 13 Jun 2013 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/openssl-encrypt-data-with-rsa-key-with/</guid>
      <description>Web application security is built upon a series of interconnected building blocks.&#xA;This post is part of Rietta&amp;rsquo;s ongoing coverage of encryption. Browse the Encryption tag for the rest of the series.&#xA;Last year, I wrote about how Generating an RSA Key from the Command Line in OpenSSL could support encrypting or validating data in an unattended manner (where the password is not required to encrypt). A few weeks before that, I posted about how to Encrypt a File with a Password from the Command Line using OpenSSL.</description>
    </item>
    <item>
      <title>mod_deflate: Dramatic website speed increase with Apache compression on Ubuntu Linux</title>
      <link>https://rietta.com/blog/moddeflate-dramatic-website-speed/</link>
      <pubDate>Wed, 18 Apr 2012 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/moddeflate-dramatic-website-speed/</guid>
      <description>It&amp;rsquo;s easy to dramatically improve the loading speed of your website by enabling compression support in your Apache web server. This works without needing to make any changes to your backend or database code no matter what programming platform your development team uses.&#xA;I recently added this change to a Ruby on Rails-based web application running on a Ubuntu Linux dedicated virtual server. That particular page observed a 72% decrease in bandwidth required to deliver the homepage.</description>
    </item>
    <item>
      <title>Rails: TypeError: nil can&#39;t be coerced into Float</title>
      <link>https://rietta.com/blog/rails-typeerror-nil-cant-be-coerced/</link>
      <pubDate>Sat, 14 Jan 2012 00:00:00 +0000</pubDate>
      <guid>https://rietta.com/blog/rails-typeerror-nil-cant-be-coerced/</guid>
      <description>When working on Ruby on Rails website some of the common errors that you need to check for is nil objects when something else was expected. For instance, suppose one of your ActiveRecord models has a price field. Further suppose that the user left this field blank instead of entering 0.0 as the price.&#xA;This computation will fail: quantity = 3 # ... amount_to_charge = price_field * quantityIt fails with a &amp;ldquo;TypeError: nil can&amp;rsquo;t be coerced into Float&amp;rdquo; exception.</description>
    </item>
  </channel>
</rss>
