I don’t believe that either section of the Constitution would need amendment.
The power to make laws (s51) is a right not an obligation.
The Commonwealth Electoral Act would however need amendment (in relation to s24 of the Constitution) and, yes, the Census and Statistics Act would need amendment (or repealing).
Just curious but the Census was deferred twice in history. Did that require an amendment to an Act?
Honestly, I don’t see this as a controversial change. Couldn’t the Census be killed with bipartisan support if it is no longer necessary?
A fairly comprehensive discussion but perhaps overly pessimistic. You are still better off using any kind of 2FA than not.
Quoting from the linked linked article:
Last year, Weinert [Director of Identity Security at Microsoft] noted that using any form of MFA is better than relying just on a password for security, as it “significantly increases the costs for attackers, which is why the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.”
The weaknesses in SMS for 2FA are usually actually weaknesses elsewhere. For example, the article talks about Modlishka but as far as I can tell that is just a nicely engineered MITM (Man In The Middle) attack and you are supposed to notice when the web site you connected to is the wrong web site. Once a MITM attack succeeds, no form of 2FA will fully protect you.
I would be very wary of Microsoft pushing its own 2FA solution or indeed any Big Tech 2FA solution. We’ve seen that story before, how a small number of companies get to dominate a market with proprietary, closed, lock-in, unauditable, unverifiable solutions.
After I did a clean re-install of Windows 10 on our PC a couple of years ago and I went to set up the password I had previously used, which consisted of upper and lower case letters and 4 numbers, it advised that I should use a PIN instead of a password for greater security, so I simply just used the 4 numbers instead.
Online retailers should be barred from collecting data about a consumer from another company, unless the consumer has clearly and actively requested this.
For example, this could involve clicking on a check-box next to a plainly worded instruction such as:
Please obtain information about my interests, needs, behaviours and/or characteristics from the following data brokers, advertising companies and/or other suppliers.
The third parties should be specifically named. And the default setting should be that third-party data are not collected without the customer’s express request.
This rule would be consistent with what we know from consumer surveys: most Australian consumers are not comfortable with companies unnecessarily sharing their personal information.
There are definitely good ones. I use Google Authenticator and it’s entirely stored on the user device as far as I can tell. Google doesn’t hold the encrypted data, nor the key to unlock it.
But we agree that really you have no way to tell whether it works or how it works? Unverifiable. Unauditable.
In the typical scenario of usage, it is being used online, and unavoidably so i.e. it would not work if you pulled the device off the internet. Therefore you have no way of knowing for sure that the important bits are held only locally and/or what information is transmitted on the internet.
You have no way of knowing what information is recorded by the provider of the authentication service, incidental to the process of authentication. Given that Google’s business model is to record everything about you and then use that information to make money (aka surveillance capitalism) … why would anyone want a third party web site, product or service using Google Authenticator?
I have no problem if a Google web site, product or service uses Google Authenticator. If you’ve made the choice to use a Google web site, product or service then you’ve already made the choice to sell your privacy.
But let’s say hypothetically that Choice decides that a password is too weak to log in to this forum, and so they will use 2FA, and, well, they don’t have the time or expertise to build their own 2FA app, so they just outsource the task to Google. Now anyone who wants to post into this forum has to give Google surveillance rights over their use of the forum (when, how often, …) and one-off you have to provide some information to Google and you have to run their software (app) on your phone.
2FA is only required the first time you log in from a new device generally. So that information would not be accessed by Google. Nor does the app require the internet to use (only for initial setup).
As for the encrypted data, it is not within the scope of Google’s privacy policy to collect it (it’s not a form of personal information, not within the scope of ‘how you use our services’ and not information you provide separate consent to upload). In order to transfer the data from your app, you have to actually manually transfer it (a QR code system assists in this), it’s not stored on the cloud for the user.
I’m not a fan of how google operates, but we need to understand things before we criticise them.
One suspects that this was less ‘hacking’ and more ‘he forgot to remove access’.
Choice would be absolutely crazy to build its own 2FA app. Even experts get it wrong way too often.
The only thing Google actually sees in its 2FA app is when you set up a new website. The app constantly generates numbers whether you use them or not. It is unclear to me whether the website is required to contact Google to confirm the authentication number, but there would be no logical reason for it to have to do this.
If you are worried about Google, there are plenty of alternatives. Just bear in mind that anything related to security/privacy can be difficult. This site, for instance, recommends andOTP - whose author stated on Reddit two years ago that:
I sadly have to admit that the part about the crypto of andOTP being pretty bad is true. This is partially due to the fact that I had absolutely no clue about cryptography and very little coding experience when I forked it. In the beginning I just wanted to add backup functionality but then feature request kept comming in and it kind of snowballed from there. By the point I had enough experience to actually somewhat know what I was doing the code was already pretty bad, which is why I decided to rewrite everything from scratch rather than trying to fix it. Sadly I currently have basically no time to work on it, so this will have to wait.
Allegedly fixed since then, but even now I would say that the lack of experience is a big red flag given the multiple ways even professionals can mess up security.
I strongly agree. As I wrote, they don’t have the expertise. Maybe my slightly flippant language didn’t make that clear.
But the choice would not be in my hands. The choice would be in the hands of the web site operator, in this case (hypothetically) Choice. If they choose third-party authenticator, XYZ, I may have only two choices: be a read-only user of the Choice web site or install XYZ’s authenticator app.
Is any claim about how an app operates verifiable?
Obviously for open source then, yes, up to a point. I could be wrong but I think for iOS, you may have to buy an Apple computer (i.e. $$$) in order to build apps, and building apps from source is the only way to be sure that the open source is actually the code that is in use. For Android, I think you have a better chance. Building apps from source is also the only option if you choose to avoid Apple and Google.
Even if you can’t understand the crypto code, you should be able to find out and understand what transmissions occur and what local information is accessed - which would be the main concerns from a privacy perspective, as distinct from a security perspective where the crypto itself becomes the most significant thing. Both perspectives are important.
Whenever you deal with any business or access any page on the internet you are trusting that the privacy policy of the business is accurate. Personally, I think Google would be likely to have a more accurate privacy policy than many smaller businesses who may not be aware of data storage and disclosure laws.
Hell, even the WA government check in app recently ran into this problem. The privacy policy stated that data was only available to the health department, when it turns out the police were able to legally access it due to a loophole in the law (which has since been fixed).
If we live our lives totally questioning every single time we share details, we’d be sitting at home in the dark with nothing. Yes, question privacy issues. No, I’ve not yet seen any reason whatsoever that there is some shady privacy issue with authenticator apps.
A link to post in another topic but a concern regarding security and intrusion
Should such systems be disclosed when seeking to purchase a Smart device? You may still not end up having any other choice that doesn’t include it but at least you would be aware of the system and be forewarned of possible inconvenience in the future. Big business able to choose what benefit you get out of a device after you own it seems contrary to that definition of ownership.
I read up a bit on this. The bottom line is the same: you are left with a lot of unverifiable claims about what either end is doing.
For the app side of it, you should be able to deny the app access to the network permanently. If the app doesn’t work without access to the network then that is a massive red flag.
For the web site side of it, the big question is how much of it is implemented on the server that hosts the web site of the company in question and how much of it is implemented remote to that server. (There may be some security advantages in keeping authentication remote from that server but there are obvious privacy disadvantages.) There are too many web sites where third parties have their hooks in the web site. (I think this is the basic question that you were raising.)
Another issue is what information is passed from the web site to the authenticator app at the time of set up. I have read that the answer is: email address/username, issuing web site, secret password (could be random and not even known to the user) - but that is not something that I have personally verified. Exactly what happens to the first two pieces of information I have no idea but clearly they are not something that you would necessarily want to share with a third party.
Another question on the app side is: How securely is the information stored? And the flip side of that: How do you back it up? (The backup itself is a potential exposure. Any backup that is dependent on the authentication provider is, in my opinion, completely unacceptable. You want a backup because otherwise you may completely lose access to the web site and profile and content … but, as said, you don’t want the backup to fall into the wrong hands.)
If you have more than one device Google Authenticator allows you to use a QR code to copy your data to another app. At this point the data does flow through Google’s servers to transfer, with the QR code giving the new device the data address (and potentially key to decrypt it). This is only doable while you keep the QR code open on your existing app. When you close it the data no longer accessible with a QR code.
I wasn’t able to do this with my last phone (as I traded in the old one for the new one), but I had suitable TFA backups such as backup codes (provided when you first set up TFA for a site. You can save them as a text document)
Given that the data can be configured initially into the app using a QR code, it would make more sense to transfer it directly from one phone to another by reproducing the original QR code on the source phone and scanning it on the other phone. (It isn’t a lot of data. Quite small compared to, say, an EU vaccination passport.) However maybe it works the way you say.
