2018-02-18 - Re: [GRASE-Hotspot] Wish list

Header Data

From: Charles Chambers <cc***2@gmail.com>
Message Hash: 1b08f59f3ed1b87ec2b4387117002ec765813c2cdb6cd047a7488c7359acf073
Message ID: <303ec934-3e2c-9466-ccda-0383cf145248@gmail.com>
Reply To: <CAESLx0LfwP3fBht81gtdB=J6pPAwfjG-L9W8Uvp-bYKT31vG7w@mail.gmail.com>
UTC Datetime: 2018-02-18 04:54:59 UTC
Raw Date: Sun, 18 Feb 2018 04:54:59 -0700

Raw message 

Hi, Tim:


Not a real serious problem, as noted below.  Just a couple of wishes.


On 02/18/2018 03:04 AM, Timothy White wrote:
> Hi Charles
>
> Payment portal integration & self registration need to wait until I
> finish the PHP7/Symfony framework upgrades. They are #1 on the list at
> the moment, as Ubuntu 12.04 is already out of general support, and
> 14.04 is out of support next year. So by the end of the year, we need
> to support 16.04 and 18.04, which requires a PHP7 upgrade, which
> requires the Symfony framework change. There are github issues for the
> portal already.
 When you can get to it.  Payment portal and self registration go hand
in hand in reducing the overhead in signing up users.  If they can sign
themselves up, and pay for themselves, then there's no overhead beyond
machine time.

> Auto redirection with SSL. Not sure which way you are asking. If it's
> redirecting SSL pages (i.e. someone tries to go to https://google.com,
> and the captive portal redirects that), then that's not going to
> happen. Due to how SSL works, this just isn't possible. It's also not
> needed, as most modern browsers correctly detect captive portals
> anyway. If you are asking that we make the login page SSL, that is
> possible, but harder. It requires that we have a public IP address and
> hostname that we can get a certificate for. Even with Letsencrypt,
> this is still more difficult to automate and setup out of the box.
> Hopefully in the future we can make this easier to do, with clear
> instructions.
> However, what you may not realise, is that even without SSL, we are
> already pretty secure on the login page. This is because we do CHAP
> authentication, (assuming you don't disable the JS login), which
> ensures the password isn't ever sent over the wire, only the CHAP
> challenge and response. (This is also the reason the password is in
> clear-text in the database, no other way to do CHAP).

With wifi, you can't secure your medium.  Especially not public wifi.

My thinking, in broad strokes, would be that all traffic between user
and portal should be encrypted in some way.  It should take significant
computing resources to packet sniff, analyze, and decrypt a customer's
data stream, whether or not it contains personal or financial
information that needs protection.  Enable IPv6 fully, and you can do
that, but I'm not sure how that works from a user experience.

Until IPv6 is available, my $0.02 is that this needs a "hopefully sooner
rather than later" priority.  *Most* conventional business sites will
encrypt when the user goes to provide personal or financial information,
and the encryption runs from the user's browser to the information
recipient's server - for example, from me to my bank.  That's the
general purpose of SSL, and that's all well and good.   It doesn't cover
the user communicating with all sites, however, and I can think of
reasons why privacy would be important. 






>
> Hope that gives you the information you needed.
>
> Regards
>
> Tim
>
>
>
> On 18 February 2018 at 00:34, Charles Chambers <cc***2@gmail.com> wrote:
>> Hi, Tim and all:
>>
>> I'm done evaluating.  This is pretty good.  I wish I were more competent at
>> extending it, but I AM struggling at it.
>>
>> I have a couple of wishes, if anyone has done anything extending the package
>> recently.  If not, it can be swallowed up in the upcoming release.
>>
>> 1)  Payment portal integration *and* self registration would cut back on
>> cashier interaction.  Has there been any progress on this?
>>
>> 2)  Autoredirection of the login page to a secure (SSL secure) page for
>> credentials.  Same for payment portal and self registration pages.  Has
>> anyone else asked about this?
>>
>> I'd rather not deploy without at least considering security issues.
>>
>> Charlie
>>
>>
>> --
>> This mailing list is for the Grase Hotspot Project http://grasehotspot.org
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Grase Hotspot" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gr***e@grasehotspot.org.
>> To post to this group, send email to gr***t@grasehotspot.org.
>> Visit this group at
>> https://groups.google.com/a/grasehotspot.org/group/grase-hotspot/.
>> To view this discussion on the web visit
>> https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/84728c1a-4c62-4f52-b6cd-d04ce6c7b0cc%40grasehotspot.org.

Thread